Your SlideShare is downloading. ×
  • Like
  • Save
Lucidi a supporto dell'insegnamento di Collaborazione e Supporti Tecnologici - Master ASIDI 2013
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Lucidi a supporto dell'insegnamento di Collaborazione e Supporti Tecnologici - Master ASIDI 2013

  • 363 views
Published

 

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
363
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Collaborazione e SupportiTecnologici Master ASIDI - 2013 Università degli Studi di Milano-Bicocca Dott. Ing. Federico Cabitza
  • 2. Introduzione • about.me/FedericoCabitza • http://goo.gl/eSHm9
  • 3. What's in a name? (Romeo and Juliet, II, ii, 1-2;William Shakespeare)
  • 4. What's in a name? (Romeo and Juliet, II, ii, 1-2;William Shakespeare) Collaborazione e Supporti Tecnologici
  • 5. What's in a name? (Romeo and Juliet, II, ii, 1-2;William Shakespeare) Collaborazione grazie a? Supporti Tecnologici
  • 6. What's in a name? (Romeo and Juliet, II, ii, 1-2;William Shakespeare) Collaborazione nonostante? Supporti Tecnologici
  • 7. What's in a name? (Romeo and Juliet, II, ii, 1-2;William Shakespeare) Collaborazione CON Supporti Tecnologici
  • 8. Cosa? 1. Definire dei Concetti, a cui sono affezionato e che penso vi possano servire – ArticulationWork|SocioTechnicalSystem|Appropriation |TaskArtifactCycle|Evaluation|UnintendedConsequenc es|RequirementElicitation|Errors|Feedback|Workflow| Workaround
  • 9. Cosa? 2. Fornire strumenti, per rappresentare i fenomeni legati alla collaborazione – ArticulationWork|SocioTechnicalSystem|Appropriation |TaskArtifactCycle|Evaluation|UnintendedConsequenc es|RequirementElicitation|Errors|Feedback|Workflow| Workaround
  • 10. Cosa? 3. Sperimentare gli strumenti recuperando la propria esperienza lavorativa – ArticulationWork|SocioTechnicalSystem|Appropriation |TaskArtifactCycle|Evaluation|UnintendedConsequenc es|RequirementElicitation|Errors|Feedback|Workflow| Workaround
  • 11. Quando?  6 lezioni frontali  2 elaborati in cui inquadrare gli argomenti nella propria esperienza professionale.  4 mesi di discussione online  21/03::04/04 18/04::09/05 30/05::26/07
  • 12. Perché? Requirement definition System Design Subsystem Development System Integration System decommissioning System Evolution System Operation System Installation Modello a cascata di produzione dei sistemi informatici, concepito per il Whirlwind negli anni 60, mutuando approcci dalle ingegnerie “hard”; già “esorcizzato” da Royce nel 1970; ottimamente applicato fin nel 2013 in tutto il mondo (a meno di qualche retroazione “cosmetica”, o resasi necessaria).
  • 13. Perché? Requirement definition System Design Subsystem Development System Integration System decommissioning System Evolution System Operation System Installation Il tecnico sanitario di radiologia medica ha anche la responsabilità di saper usare (gestire?) sistemi informatici complessi; quindi è bene che acquisisca competenze a largo spettro nell‟intera filiera della produzione di tali sistemi.
  • 14. Come? Give a human being a truth and he will think for a day Show a human being how to reason and he will think for a lifetime Cf. Philip Cary Plait speech at TAM 8, 2010
  • 15. L‟amara verità sui supporti tecnologici… Dal 60% all’80% dei progetti di informatizzazione in ambito organizzativo/aziendale (e soprattutto sanitario ospedaliero)
  • 16. L‟amara verità sui supporti tecnologici… Dal 60% all’80% dei progetti di informatizzazione in ambito organizzativo/aziendale (e soprattutto sanitario ospedaliero) fallisce
  • 17. L‟amara verità sui supporti tecnologici… Dal 60% all’80% dei progetti di informatizzazione in ambito organizzativo/aziendale (e soprattutto sanitario ospedaliero)  perché non raggiungono gli obiettivi di performance,  perché sforano vincoli di budget o tempistiche,  perché i requisiti non sono soddisfatti, oppure  perché gli utenti sono insoddisfatti o non usano le tecnologie loro fornite quanto o come dovrebbero,  etc. fallisce
  • 18. L‟amara verità sui supporti tecnologici… fallisce
  • 19. Collaborare è “bello” ma… L‟amara verità sulla collaborazione
  • 20. Collaborare è “bello” ma… L‟amara verità sulla collaborazione
  • 21. Collaborazione e Supporti Tecnologici Da Grudin, Jonathan and Poltrock, Steven (2013): Computer Supported CooperativeWork. In: Soegaard, Mads and Dam, Rikke Friis (eds.). "The Encyclopedia of Human-Computer Interaction, 2nd Ed.". Aarhus, Denmark: The Interaction Design Foundation.
  • 22. Collaborazione e Supporti Tecnologici Da Johansen, R., “Groupware: Computer support for business teams,” NewYork:The Free Press, 1988..
  • 23. «Bisogna trovare le parole giuste: le parole sono importanti!» Palombella Rossa, N. Moretti 1989
  • 24. Collaborazione Condivisione di informazioni e strumenti, ma soprattutto di significati e pratiche. Coordinamento per allineare le azioni dei singoli verso obiettivi comuni.
  • 25. Coordinamento Il processo (e l‟effetto) di cum-ordinare, cioè mettere insieme in un certo ordine un insieme di vari elementi (es.: risorse, attività, prodotti) per un certo fine...
  • 26. Coordinamento Il processo (e l‟effetto) di cum-ordinare, cioè mettere insieme in un certo ordine un insieme di vari elementi (es.: risorse, attività, prodotti) per un certo fine. A proposito, come si dice Computer in Francese e in Spagnolo?
  • 27. Digressione Étymologie du mot ORDINATEUR : ordinateur (ancien français)... mais si ordinateur a bien pour étymologie le mot ordinateur de l'ancien français, celui-ci provient lui-même de l'évolution du mot latin ordinator.Ordinateur avait autrefois le sens d'ordonnateur, personne qui dispose, qui règle selon un ordre. Dans l'Église catholique, il avait aussi le sens d'ordinant, celui qui confère un ordre ecclésiastique. En 1954, la société IBM France voulait trouver un nom français pour sa nouvelle machine électronique destinées au traitement de l'information (IBM 650), en évitant d'utiliser la traduction littérale du mot anglais "computer" ("calculateur" ou "calculatrice"), qui était à cette époque plutôt réservé aux machines scientifiques. Aux États- Unis, les nouvelles machines de traitement automatique de l'information (capables de faire aussi du traitement de texte, du dessin, etc.) étaient appelées "electronic data processing systems" (EDPS) ou "data processing machines". Un cadre de la société conseilla de consulter un de ses anciens professeurs, Jacques Perret, titulaire de la chaire de philologie latine à la Sorbonne. Le professeur Perret répondit par une lettre du 16 avril 1955, dont la lecture donne un exemple intéressant de recherche terminologique : Que diriez vous d'"ordinateur" ? C'est un mot correctement formé, qui se trouve même dans le Littré comme adjectif désignant Dieu qui met de l'ordre dans le monde. Un mot de ce genre a l'avantage de donner aisément un verbe, "ordiner", un nom d'action, "ordination". L'inconvénient est que "ordination" désigne une cérémonie religieuse ; mais les deux champs de signification (religion et comptabilité) sont si éloignés et la cérémonie d'ordination connue, je crois, de si peu de personnes que l'inconvénient est peut-être mineur. D'ailleurs votre machine serait "ordinateur" (et non ordination) et ce mot est tout a fait sorti de l'usage théologique. "Systémateur" serait un néologisme, mais qui ne me paraît pas offensant ; il permet "systémation" ; mais "systémer" ne me semble guère utilisable. "Combinateur" a l'inconvénient du sens péjoratif de "combine" ; "combiner" est usuel, donc peu capable de devenir technique ; "combination" ne me paraît guère viable à cause de la proximité de "combinaison". Mais les Allemands ont bien leurs "combinats" (sorte de trusts, je crois), si bien que le mot aurait peut-être des possibilités autres que celles qu'évoque "combine". "Congesteur", "digesteur" évoquent trop "congestion" et "digestion" "Synthétiseur" ne me paraît pas un mot assez neuf pour designer un objet spécifique, déterminé comme votre machine. En relisant les brochures que vous m'avez données, je vois que plusieurs de vos appareils sont désignés par des noms d'agents féminins (trieuse, tabulatrice). "Ordinatrice" serait parfaitement possible et aurait même l'avantage de séparer plus encore votre machine du vocabulaire de la théologie. Il y a possibilité aussi d'ajouter à un nom d'agent un complément : "ordinatrice d'éléments complexes" ou un élément de composition, par ex. "sélecto-systémateur". "Sélecto-ordinateur" a l'inconvénient de deux "o" en hiatus, comme "électro- ordinatrice". Il me semble que je pencherais pour "ordinatrice électronique"… IBM France retint le mot ordinateur et chercha au début à protéger ce nom comme une marque. Mais le mot fut facilement et rapidement adopté par les utilisateurs et IBM France décida au bout de quelques mois de le laisser dans le domaine public. On peut certes épiloguer sur le choix du terme : un ordinateur met-il vraiment en ordre ce qu'on lui confie ? De ce point de vue, ce choix n'est pas plus critiquable que celui du mot "computer", finalement retenu en anglais (un ordinateur n'est pas seulement une machine à calculer). L'avantage du mot ordinateur est que son sens ancien et son sens religieux ne sont pas connus par la plupart des utilisateurs et qu'il est donc sans ambiguïté pour eux. Le mot a d'ailleurs été transposé en espagnol (ordenador) et en catalan (ordinador). Les autres langues romanes ont choisi de construire un néologisme à partir des mots latins calculator et computator : computadora en espagnol d'Amérique latine, calcolatore en italien, computador en portugais et calculator en roumain. (da http://www.presse-francophone.org/apfa/motdor/etymolog/ordinate.htm)
  • 28. …tenendo in considerazione le dipendenze tra compiti e risorse e gestendo eventuali conflitti. Coordinamento Shared resources Producer Consumer Common Object Task consumes Multiple resources Task consumes a resource and produces another Task produces Multiple resources Task Resource Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys (CSUR), 26(1), 87-119.
  • 29. Protocolli • Il coordinamento è garantito dall‟esecuzione di protocolli, cioè insiemi di regole che specificano chi si aspetta che cosa, in che formato, da chi, in quale ordine, entro quando. • Una regola ha una natura «descrittiva» o «ostensiva» cioè o indica una regolarità di comportamento, o costituisce un criterio di condotta corretta. (Schmidt 2010) – Cf.Turing e Wittgenstein sul concetto di rule
  • 30. Informatica • Inscrivere un protocollo in una macchina affinché questa, sulla base delle sue regole, ordini cose (solitamente solo simboli; ma questi sono segni per gli esseri umani, e quindi significati, e quindi risorse per l‟azione, tramite l‟interpretazione)
  • 31. Informatica • Inscrivere un protocollo in una macchina affinché questa, sulla base delle sue regole, ordini cose • Diventa quindi interessante considerare: • Chi definisce le regole? Chi è coinvolto nella loro esecuzione? Che valore ha il nuovo ordine delle cose, e per chi? Che impatto ha il nuovo ordine sulle persone e i loro valori? Qual è il grado di «completezza» e «precisione» delle regole rispetto a quella porzione di mondo a cui impongono il loro ordine? Cosa succede se una o più regole sono totalmente o parzialmente aggirate?
  • 32. Lessico Comune • Ci servono le parole per cercare quanto meno di «pensare» quelle domande. • ArticulationWork|SocioTechnicalSystem| Appropriation|TaskArtifactCycle
  • 33. Articulation Work • Lavoro volto a comprendere e gestire le mutue interdipendenze tra risorse, azioni ed eventi (Schmidt, 92). • Lavoro necessario a co-ordinare linee di lavoro diverse e «mutuamente dipendenti» verso un obiettivo comune (Strauss, 85) • Lavoro per mettere insieme elementi diversi in configurazioni efficaci a qualche scopo (Suchman, 96) • Comprende «assembling, scheduling, monitoring, and coordinating all of the steps necessary to complete a production task» (Gerson&Star, 1996)
  • 34. Articulation Work • E‟ un lavoro che abilita il lavoro, ma non è prerogativa dei manager, non è «gestione», è permettere il lavoro collaborativo. • Comprende l‟applicazione di protocolli di interazione e coordinamento. • Ma anche la conoscenza (tacita) di convenzioni locali, di abitudini informali di lavoro, delle peculiarità dei colleghi, di aspetti quasi «stigmergici» dell‟ambiente fisico in cui si lavora (awareness).
  • 35. • E‟ un lavoro che abilita il lavoro, ma non è prerogativa dei manager, non è «gestione», è permettere il lavoro collaborativo. • Comprende l‟applicazione di protocolli di interazione e coordinamento. • Ma anche la conoscenza (tacita) di convenzioni locali, di abitudini informali di lavoro, delle peculiarità dei colleghi, di aspetti quasi «stigmergici» dell‟ambiente fisico in cui si lavora (awareness). Articulation Work
  • 36. Socio-technical System • E‟ un sistema. un insieme di elementi interrelati ed eventualmente mutuamente dipendenti che agli occhi di un osservatore esterno appaiono come una entità unitaria ma collettiva, con caratteristiche e comportamento proprio, solitamente autonomo ed intenzionale (cioè volto ad un obiettivo)
  • 37. • Un sistema in cui la componente umana (sociale) e quella tecnica (tecnologica) sono inestricabilmente legate tra loro (cf. interdipendenza) – È un concetto ad invarianza di scala • dal piccolo team di lavoro alla società umana • Noi siamo interessati al «luogo di lavoro» «workplace» Socio-technical System
  • 38. • Un sistema in cui la componente umana (sociale) e quella tecnica (tecnologica) sono inestricabilmente legate tra loro (cf. interdipendenza) e la loro interazione porta a fenomeni emergenti impredicibili. • Le proprietà/comportamento del sistema non sono desumibili da quelle delle sue parti, prese isolatamente, ma bensì emergono proprio in virtù delle interazioni tra quelle (analisi solo post-hoc) in un determinato ambiente (analisi locale). Socio-technical System
  • 39. • Proprietà emergenti: • Funzionali, che riguardano il funzionamento dell‟intero sistema una volta che tutte le sue parti, assemblate come devono, funzionano bene. • La bicicletta Socio-technical System
  • 40. • Proprietà emergenti: • Non funzionali, che riguardano quanto bene opera il sistema in un determinato ambiente/contesto, ad es.: reliability, security, performance, safety, usability.Ad esempio: • le informazioni sono giuste ma non aggiornate (inserite solo a fine turno); • il sistema richiede la password per il log in ma questa è stampata su un post-it attaccato al monitor; • il sistema prevede la verifica con barcode, ma il filo della “pistola” è troppo corto; • è tutto perfetto, peccato che sia scritto così maledettamente in piccolo! Socio-technical System
  • 41. • Trist (Tavinstock Institute, 1951) notò come la produttività non poteva essere spiegata solo in termini di ottimizzazioni tecniche (strumenti e strutture, quali la specializzazione e la divisione del lavoro) ma anche e soprattutto come effetto di regole sociali (cf. Stakhanov), aiuto reciproco, senso di appartenenza, apprendimento, benessere sociale. – Rottura con la tradizione teoretica/scientifica che separa teoria e pratica (Taylorismo), e dall‟approccio meccanicistico (l‟organizzazione è una macchina) che considera le persone componenti funzionali dell‟organizzazione (Fordismo). • Sistema come macchina (componenti e relazioni) vs. Sistema come fenomeno complesso (cf. pressione e temperatura) • Utenti e ruoli vs. Attori in una rete • Progettazione vs. Co-costruzione partecipativa • Ciclo di vita del prodotto/sistema vs. e ciclo task-artifact. Socio-technical System
  • 42. • Un approccio che è consapevole che le due componenti si «ottimizzano» solo congiuntamente, in configurazioni subottime (joint optimization). – Attenzione rinnovata a job satisfaction, workers‟ needs, and skill enhancement (anche in tempi di BPR, lean,TQM) • L‟introduzione di una tecnologia in un contesto lavorativo (quindi sociale) è parte di un processo di cambiamento operante su più piani, che può essere previsto in maniera solo molto approssimativa e che va gestito in maniera molto focalizzata, in virtù di una conoscenza molto approfondita degli aspetti sociali di un certo workplace. Socio-technical System
  • 43. • Cosa cercare, cosa guardare… sociale tecnica Persone Non solo ergonomia (uomo- macchina) ma anche la dimensione sociale, la conoscenza tacita, le convenzioni, le “unwritten rules” Tecniche (tra cui procedure, protocoli, divisione del lavoro, written policies and rules) Socio-technical System
  • 44. Socio-technical System • Questi sono esempi di sistema socio-tecnico…
  • 45. Appropriation • Non sempre gli utenti «stanno alle regole» (play to the rules - Dix). – Fenomeno del Workaround, che coglie uno spettro ampio di comportamenti, da quelli estremi di «non uso», «misuso» o «sabotaggio» a quelli più creativi e positivi della appropriazione...
  • 46. Appropriation • Il processo attraverso cui le persone adottano e adattano le tecnologie fornite loro per lavorare e le rendono «fit» (adatte) alle loro pratiche di lavoro. (Dourish, 2003) – Può comprendere (ma in realtà trascende) la customizzazione, poiché riguarda anche la trasformazione della pratica, ad un livello profondo.
  • 47. Appropriation • «making the possibilities of the artifact available to one self» «make use» «make sense» – Non è semplice «adozione», poiché comprende l‟aggiunta di modalità d‟uso non previste, significati priorità locali finalità andare oltre le idee concepite in analisi, o le intenzioni dei progettisti.
  • 48. Appropriation Esempi: usare un cacciavite per aprire una lattina di vernice usare un librone per non far sbattere una porta mandarsi una email per memorizzare un link di interesse o mandarsi un allegato per salvare un documento fare due squilli al cellulare per far sapere che si è pronti a fare una cosa
  • 49. Appropriation Ultimo esempio: l‟#hashtag di Twitter (etichette di testo utilizzate nei social network) #sandiegofire (2007) 1) Il sistema era abbastanza flessibile da permettere un unanticipated use da parte degli utenti (usi con finalità o significati non anticipati dai progettisti) 2) Gli sviluppatori sono stati ricettivi delle convenzioni d‟uso degli utenti e li hanno integrati nelle versioni successive (2009)
  • 50. Appropriation • Quindi non c‟è vera appropriazione se non si è mossi dall‟idea di raggiungere un proprio obiettivo (od organizzativo) ma a modo proprio e con lo strumento • E‟ un tipo di improvvisazione (ad-hocness), adottato – perché funziona perché è più efficiente perché è più facile perché si ignora il modo «giusto» perché così ci si sente un po‟ «proprietari» della tecnologia
  • 51. Appropriation • Come si può supportare l‟appropriazione da parte degli utenti dei propri strumenti informatici? – Strumenti che permettono maggiore customizzazione. Si pensi anche solo alle etichette delle email in Gmail, i colori di file e cartelle in MacOS, alle icone posizionabili sul desktop! – Più risorse dedicate all‟addestramento (uso) alla formazione (senso) alla cultura del cambiamento
  • 52. Appropriation • Come si può supportare l‟appropriazione da parte degli utenti dei propri strumenti informatici? – Ma soprattutto: più coinvolgimento nella progettazione (participatory design) più feedback dopo il deployment (meta-design) più spazio per l‟End User Development (mashups, ...) più preparazione (culturale) da parte dell’End User.
  • 53. Appropriation • Questo concetto ci permette di distinguere tra – Technology-as-designed / Technological artifact vs. – Technology-in-use / Technology-in-practice (Orlikowsky, 2000; Carroll, Jennie, et al. 2001) • Dove finisce il design e inizia l‟uso? (Meta-design, Fischer&Giaccardi, 2006) • Meglio: dove finisce il compito e inizia lo strumento?
  • 54. Task Artifact Cycle • Metafora del fatto che il task e gli strumenti che lo supportano co-evolvono. (Carroll, John et al. 1991) • Processo iterativo di sviluppo continuo e mutuamente dipendente tra task e supporto informatico che non raggiungerà mai uno stato ottimo (e se questo accadrà, non sarà permanente) • E‟ l‟antidoto contro le metodologie di sviluppo.
  • 55. Task Artifact Cycle Artifact Task Use, Adoption, Appropriation… Requirements, HCI Theory, Design… Spot the difference! vs.
  • 56. • Il problema del modello a spirale sta nel mito dello “start”, nell‟idea che • Non preesista un sistema socio-tecnico, e che l‟oggetto della discussione sia un sistema informatico bello e finito (più o meno migliorabile) • e non piuttosto un componente tecnico il cui impatto sul “resto” del sistema è ignoto. – Unintended consequences… • e che cambi con una dinamica inadeguata rispetto alla resto del sistema… Task Artifact Cycle
  • 57. Tutto cambia, tutto scorre • Il task (obiettivo), i processi (organizzazione), le pratiche (il fare delle persone) e le persone. – Biogna chiedersi in che misura l‟introduzione (o evoluzione) di una componente tecnica implica cambiamenti nella dimensione umana del sistema sociotecnico.
  • 58. Tutto cambia, tutto scorre • Possibili risposte: – De-skilling? (cf. Fridell et al. 2007) – Perdita di posti di lavoro? (cf. Sacco et al., 2000) – Insoddisfazione (abitudini modificate)? meno flessibilità, ritmi più alti – Rapporti di potere modificati o sovvertiti? • più o meno potere agli end-users? • Lavoro più “visibile”, più legittimato, ma anche più “controllato”, più automatizzato, meno “prezioso”…
  • 59. • Articulation work: – C‟è anche un lavoro che abilita e rende proficuo il lavoro e non si tratta del lavoro di “gestione” ma di coordinamento e comprensione/gestione delle interdipendenze. – Esperti di questo lavoro non sono i progettisti, o (solo) i manager, ma proprio gli “operativi”, che detengono una conoscenza (di dominio) spesso tacita e informale. – L‟informatica non riguarda solo macchine per l‟elaborazione di informazioni, dati (input/output) e algoritmi (funzioni) … …ma anche protocolli per l‟ordinamento delle cose del mondo, la comunicazione, e il controllo dei flussi aziendali… … e ovviamente le macchine che enactano tali protocolli. • Computer Systems are Perfect Bureaucratic Tools! (Harris & Henderson 1999) • Computer are but “command and control” systems. (Norbert Wiener, 1948) A che punto siamo?
  • 60. A che punto siamo? • Socio-Technical System::Appropriation::TaskArtifactCycle – Contrastare i miti • che un sistema informatico sia “dato” in un certo ambiente di lavoro,“fornito” da qualcuno di esterno,“as is”, che abbia “bachi” o mancanze “assolute” o qualità intrinseche (indipendenti dal contesto). (cf. Goal Rail c/o Trenord, 2012) • Che il “design” possa mai dirsi “completo”, finito, o che possa essere inteso “disincarnato”, cioè avulso dall‟uso (cf.Taylor) • Che l‟utente (cf. Don Norman) sia esterno al sistema o giusto l‟elemento terminale (end user) del processo di produzione. Anzi è lui l‟esperto da coinvolgere nella progettazione e nella valutazione del sistema tecnico.
  • 61. Perchè questi concetti • Se un sistema sociotecnico è un sistema…
  • 62. Perchè questi concetti Fornitori ICT TSdRM Ospedale • Elicitazione Requisiti • Valutazione dell’impatto • Feedback per evoluzione Radiologia outcomes Mercato, Direttive Regionali, Raccomandazioni, Portfolio clienti, … • …allora si possono concepire tre interventi.
  • 63. Modalità d‟esame • Per l‟esame vi propongo due elaborati: – Uno per il gruppo grande (6-7 persone) • Migliorare il processo di refertazione che si trova su Wikipedia (ad pera di un ingegnere elettronico) – http://it.wikipedia.org/wiki/Sistema_informatico_radiologico#Processo_di_refertazione • basandolo su un caso d‟uso articolato e BPMN. • da rappresentare su piattaforma collaborativa (Oryx). – L‟altro per un gruppo di singoletti/coppie/terzetti • Somministrare (de visu?) ai responsabili di servizio e tecnici “esperti” il breve questionario sulle “unintended consequences”. • Riportare su un documento condiviso (su Wikispaces) i risultati, gli aneddoti, le casistiche più interessanti ed eventualmente commentarle/analizzarle liberamente.
  • 64. (ISTA)
  • 65. Interactive SocioTechnical Analysis (ISTA)
  • 66. Interactive SocioTechnical Analysis (ISTA) La ISTA è un modello concettuale delle Interazioni occorrenti in un sistema socio-tecnico dopo l‟inserimento di una HIT. Una sintesi di vari approcci dalle discipline dei STSs, ergonomia, social informatics, costruzione sociale della tecnologia, CSCW. Individua cinque tipi di interazione.
  • 67. Interactive SocioTechnical Analysis (ISTA) 1: la nuova tecnologia (HIT) cambia il sistema sociale esistente.
  • 68. Interactive SocioTechnical Analysis (ISTA) 1: la nuova tecnologia (HIT) cambia il sistema sociale esistente. 2: l‟infrastruttura tecnica e fisica (legacy systems e vincoli logistici) condiziona come la HIT è installata/usata.
  • 69. Interactive SocioTechnical Analysis (ISTA) 1: la nuova tecnologia (HIT) cambia il sistema sociale esistente. 2: l‟infrastruttura tecnica e fisica (legacy systems e vincoli logistici) condiziona come la HIT è installata/usata. 3: anche il sistema sociale (cultura, pre- parazione, attitudine, risorse impiegate) condiziona l‟uso della HIT, a sua volta condizionato dalla nuova HIT.
  • 70. Interactive SocioTechnical Analysis (ISTA) 1: la nuova tecnologia (HIT) cambia il sistema sociale esistente. 2: l‟infrastruttura tecnica e fisica (legacy systems e vincoli logistici) condiziona come la HIT è installata/usata. 3: anche il sistema sociale (cultura, pre- parazione, attitudine, risorse impiegate) condiziona l‟uso della HIT, a sua volta condizionato dalla nuova HIT. 4: la HIT usata sul campo cambia il sistema sociale, a sua volta appropriata dal siste- ma sociale.
  • 71. Interactive SocioTechnical Analysis (ISTA) 1: la nuova tecnologia (HIT) cambia il sistema sociale esistente. 2: l‟infrastruttura tecnica e fisica (legacy systems e vincoli logistici) condiziona come la HIT è installata/usata. 3: anche il sistema sociale (cultura, pre- parazione, attitudine, risorse impiegate) condiziona l‟uso della HIT, a sua volta condizionato dalla nuova HIT. 4: la HIT usata sul campo cambia il sistema sociale, a sua volta appropriata dal siste- ma sociale. 5: l‟uso della HIT condiziona le evoluzioni della stessa, in funzione di come questa ha modificato il sistema sociale ed è stata appropriata da questo.
  • 72. Unintended Consequences • “law of unintended consequences”: any intervention in a complex system tends to create unanticipated and often undesirable outcomes. [Merton, 1936] • Se perturbiamo un sistema complesso (in un certo stato di equilibrio) non sappiamo come questo possa “reagire”, cioè come possa cambiare fino a raggiungere un altro equilibrio. • Le cose che in questo processo di cambiamento ci sorprendono sono dette “conseguenze inattese”.
  • 73. Unintended Consequences • “law of unintended consequences”: any intervention in a complex system tends to create unanticipated and often undesirable outcomes. [Merton, 1936] • Le conseguenze possono essere negative o positive (o neutre) – Se sono positive non parliamo di “effetti collaterali”, ma di piacevoli sorprese, di serendipità, di impatto al di là di ogni aspettativa… • Se sono negative possono esserlo – a) in quanto effetto contrario a quello che si voleva ottenere (effetto perverso, in cui una soluzione rende il problema peggiore); oppure – b) nonostante un effetto voluto sia stato raggiunto, si è verificato un effetto collaterale (negativo) imprevisto. – In entrambi i casi, pongono precise opportunità per: • decisioni organizzative, confronti tra categorie e rappresentanti, politiche di intervento che cerchino di rimediare e raggiungere situazioni di migliore tradeoff.
  • 74. • Cosa c’è dietro una “unintended consequence”? • Merton: – Ignorance : non si può sempre prevedere tutto, o crearsi un modello perfetto del mondo, o progettare contro qualsiasi eccezione ed imprevisto; – Error : non si prevede sempre correttamente, o si pensa –erroneamente- che quanto ha funzionato nel passato possa farlo anche nel futuro; – Immediate interest : (avidità) si tende a valorizzare di più gli effetti a breve termine rispetto a quelli a medio/lungo termine. – Basic values : fattori etico/comportamentali che prescrivono, vincolano (o vietano) comportamenti che darebbero (eviterebbero) una conseguenza nel lungo periodo. – Self-defeating prophecy : atteggiamento di eccessiva prudenza/cautela rispetto a certe conseguenze che è alla base di comportamenti che sono invece all’origine di quelle conseguenze. Unintended Consequences
  • 75. • In ambito di informatica medica (HIT) se ne parla (poco) da circa 10 anni – Sulla base di numerosi studi in tre continenti (USA, EU,AU) – Ash J, Berg M, Coiera E. Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. J Am Med Inform Assoc. 2003;11:104 –12. – Campbell E, Sittig D, Ash J, Guappone K, Dykstra R. Types of unintended consequences related to computerized provider order entry. J Am Med Inform Assoc. 2006;13(5):547–56. – Harrison, M. I., Koppel, R., & Bar-Lev, S. (2007). Unintended Consequences of Information Technologies in Health Care - An Interactive Sociotechnical Analysis. Journal of the American Medical Informatics Association, 14(5), 542–549. Unintended Consequences
  • 76. Unintended Consequences • Chi cerca di vendere un prodotto (o di convincere qualcuno ad investire in un progetto, o di diffondere una certa “visione del mondo”) può tacere de (o ignorare) il fatto che non sempre le cose vadano come previsto o come si vorrebbe che andassero. • Esempio molto significativo: quando un ospedale adotta un CPOE, gli eventi avversi aumentano, non diminuiscono. (Han et al., 4% mortalità in più) • Bates DW, et al. Effect of computerized physician order entry and a team intervention on prevention of serious medication errors. JAMA. 1998;280:1311–6. • Han, Y. Y., et al. (2005). Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics, 116(6), 1506-1512. • Schneider JE, Schneider KH. Report on electronic health recordassociated errors and near miss reporting systems. Rockville, MD: Agency for Healthcare Research and Quality; 2006. • Koppel R, et al. Role of computerized physician order entry systems in facilitating medication errors. JAMA. 2005;293(10):1197–203. • Ash J, Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. J Am Med Inform Assoc. 2003;11:104 –12. • Poon E, et al. Medication dispensing errors and potential adverse drug events before and after implementing bar code technology in the pharmacy. Ann Intern Med. 2006;145(5):426 –34. • Bates D. Computerized physician order entry and medication errors: finding a balance. J Biomed Inform. 2005;38(4):259–61. • Wachter R. Expected and unanticipated consequences of the quality and information technology revolutions. JAMA. 2006; 295(23):2780 –3. • Han YY, et al. Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics 2005;116(6):1506 –12 • Rosenbloom ST, et al. Perceived increase in mortality after process and policy changes implemented with computerized physician order entry. Pediatrics 2006;117(4):1452–5. • McDonald CJ. Computerization can create safety hazards: A bar-coding near miss Ann Int Med 2006;144(7):510-516. • Weiner, J. P., Kfuri, T., Chan, K., & Fowles, J. B. (2007). “e-Iatrogenesis”: The Most Critical Unintended Consequence of CPOE and other HIT. Journal of the American Medical Informatics Association, 14(3), 387–388. doi:10.1197/jamia.M2338 • Redwood, S., Rajakumar, A., Hodson, J., & Coleman, J. (2011). Does the implementation of an electronic prescribing system create unintended medication errors? A study of the sociotechnical context through the analysis of reported medication incidents. BMC medical informatics and decision making, 11(1), 29.
  • 77. Unintended Consequences • Altri esempi: – Overconfidence (Weizenbaum „76); • Fiducia che il sistema non andrà mai giù; che I suoi dati sono accurati e aggiornati. – Più lavoro (solitamente di tipo segretariale/documentale) per un personale già carico; • Fatigue-induced errors; frustrazione; insoddisfazione. – Sovvertimento delle abitudini di interazione e di lavoro • comunque efficienti a modo loro; – Conseguenze da errori di analisi e bachi del software; • Comunque indirizzabili nella fase di testing.
  • 78. One of the designers of the Royal Mail Ship Titanic, Edward Wilding, embarked at the Titanic Quarter, the place where the famous liner had been built in Belfast, and disembarked at Southampton 28 hours later, before the liner actually embarked its 3,000 passengers and began its maiden voyage; while another one,Thomas Andrews, was among those passengers and went down with the RMSTitanic trying to heroically rescue as many passengers as he could (and probably refusing to flee to safety himself). These two stories, once they have been moved to a purely symbolic level, in terms of Wildingism and Andrewism, can be taken as archetypes of different attitudes of designers in relation to “their” systems: who abandons the system soon after the “sea trials”; and who succumbs in the vain attempt to save its users. Digressione
  • 79. • Dove cercarle? • Ash, Berg e Coiera suggeriscono due dimensioni di attenzione: 1. Inserimento/recupero delle informazioni nel/dalla HIT. 2. Comunicazione e Coordinamento (non solo mediante l‟HIT). • Complementari a – Modello dei dati, Logica del flusso di controllo e Presentazione. Unintended Consequences
  • 80. • Dove cercarle? • Ash, Berg e Coiera suggeriscono due dimensioni di attenzione: 1. Inserimento/recupero delle informazioni nel/dalla HIT. 2. Comunicazione e Coordinamento (non solo mediante l‟HIT). • Berg ha però rilevato come 1 e 2 siano in realtà intrecciate Berg, Marc. "Accumulating and coordinating: occasions for information technologies in medical work." Computer Supported Cooperative Work (CSCW) 8.4 (1999): 373-401. Unintended Consequences
  • 81. • Nell‟inserimento/Recupero dei dati: – Interfacce richiedono troppa concentrazione (no interruzioni) e non sono adatte ergonomicamente. • Es.: justaxposition error Unintended Consequences
  • 82. • Nell‟inserimento/Recupero dei dati: – Informazione è troppo strutturata e codificata, secondo una idealità di completezza decontestualizzata e in fondo velleitaria. Unintended Consequences
  • 83. • Nell‟inserimento/Recupero dei dati: – Informazione è troppo strutturata e codificata, secondo una idealità di completezza decontestualizzata e in fondo velleitaria. Unintended Consequences • Garrod, Simon. "How groups co- ordinate their concepts and terminology: implications for medical Informatics." Methods of information in Medicine 37.4-5 (1998): 471. • Swinglehurst, Deborah, Trisha Greenhalgh, and Celia Roberts. "Computer templates in chronic disease management: ethnographic case study in general practice." BMJ open 2.6 (2012).
  • 84. • Nell‟inserimento/Recupero dei dati: – Informazione è troppo strutturata e codificata, secondo una idealità di completezza decontestualizzata e in fondo velleitaria. Unintended Consequences • Template troppo “ricchi” portano alla sindrome da “information overload” e a nuovi e più pesanti compiti “documentali” (paper work, record-keeping). • Workflow complessi portano ad una perdita della visione complessiva e ad un fenomeno di “fragmentazione” della pratica. • L‟approccio GUI a “point & select” porta alla perdita della pratica di “writing-as-thinking”
  • 85. • Comunicazione e Coordinamento – Visione del lavoro collaborativo come workflow lineare, predicibile e a fasi ben definite. • Es.: midnight problem. Unintended Consequences
  • 86. • Comunicazione e Coordinamento – Visione della comunicazione come trasferimento di informazione * Unintended Consequences * Coiera, Enrico. "When conversation is better than computation." Journal of the American Medical Informatics Association 7.3 (2000): 277-286.
  • 87. • Comunicazione e Coordinamento – Visione della comunicazione come trasferimento di informazione anzichè come azione (intenzionale) di qualcuno che genera un effetto o sul mondo o sul comportamento di altre persone, o semplicemente atta a verificare le nostre assunzioni sul mondo. Unintended Consequences
  • 88. • Comunicazione e Coordinamento – Visione della comunicazione come trasferimento di informazione comunicazione telefonica referti/risultati vs. il repository sempre accessibile perdita di feedback (es.: il farmaco è stato somministrato davvero?) perdita di ridondanza ** “alert fatigue” perdita di significatività di “alert” non rilevanti o pertinenti. Unintended Consequences ** Cabitza, Federico, et al. "When once is not enough: the role of redundancy in a hospital ward setting.“ GROUP 2005, ACM. § § § §
  • 89. 1. Maggior o Nuovo lavoro per i clinici: – Es.: i medici possono finire per passare più tempo di prima a documentare e giustificare le loro azioni. O possono passare più tempo a lavorare sul sistema informatico che sui pazienti. 2. Flusso di lavoro: – Es.: i sistemi informatici possono vincolare maggiormente gli operatori sanitari, che perdono discrezionalità e autonomia nel decidere sequenzialità, tempistica e modalità di esecuzione degli interventi. 3. Richieste continue di cambiamenti: – Es.: sistemi informatici mal progettati o dai tempi di rilascio troppo lunghi possono portare ad una continua richiesta di correzioni, ed evoluzioni sia manutentive che migliorative che però possono portare il sistema a cambiare troppo spesso o a rimanere troppo a lungo in condizioni di continuo test e sperimentazione. Tassonomia delle UC
  • 90. 1. Nuovo/Più Lavoro – Gli operatori sanitari possono finire per passare più tempo di prima a documentare e giustificare le loro azioni. O possono passare più tempo a lavorare sul sistema informatico che sui pazienti. – Esempi: • Multiple Passwords • Responding to alerts • Entering required information or more detailed information • Extra time to enter information Tassonomia delle UC
  • 91. 2. Problemi relativi al Flusso di lavoro – i sistemi informatici possono vincolare maggiormente gli operatori sanitari, che perdono discrezionalità e autonomia nel decidere sequenzialità, tempistica e modalità di esecuzione degli interventi. – Esempi: • System “re-orders” the workflow • HCI problems • Inconsistencies between system and policy/procedures Tassonomia delle UC
  • 92. 3. Richieste continue di cambiamenti – sistemi informatici mal progettati o dai tempi di rilascio troppo lunghi possono portare ad una continua richiesta di correzioni, ed evoluzioni sia manutentive che migliorative che però possono portare il sistema a cambiare troppo spesso o a rimanere troppo a lungo in condizioni di continuo test e sperimentazione. – Esempi: • More space required for computers • Persistent upgrades • Perpetual training • Maintenance Tassonomia delle UC
  • 93. 4. Cambiamenti nelle pratiche e nelle dinamiche comunicative – l'introduzione della tecnologia informatica porta ad un inaridimento dell'interazione tra operatori sanitari e all'eliminazione delle interazioni informali e della ridondanza naturalmente insita nella comunicazione umana, e quindi anche ad indebolire un meccanismo naturale volto a identificare o prevenire errori e sviste. – Esempi: • Loss of feedback • More paper work than care work Tassonomia delle UC
  • 94. 5. Emozioni, soddisfazione al lavoro – l'introduzione della tecnologia informatica può peggiorare la percezione del proprio ruolo in azienda, o subire decisioni, procedure non concordate, o che non prendono in consideazione i bisogni di una certa fetta di utenza. – Esempi: • Frustration and anger on the part of professionals in attempting to use systems and alter workflow. Tassonomia delle UC
  • 95. 6. Generazione di nuovi errori – interfacce web di cui gli utenti hanno poca dimestichezza o comandi dalle caratteristiche grafiche poco riconoscibili possono far introdurre errori nell'imputazione dei dati o nella loro consultazione. – Esempi: • Hidden commands/options (Scrolling and smart menus) • Justaxposition error. • Automated entry Tassonomia delle UC
  • 96. 7. Cambiamenti nella struttura del potere – l'introduzione di una tecnologia può agevolare il lavoro di un certo tipo di operatore; questo si ripercuote “in chi può chiedere cosa” e “chi risponde di cosa” e quindi alterare i rapporti di potere preesistenti in una certa organizzazione sanitaria. – Esempi: • IS/IT become authorities • Those who know how to use system leverage that knowledge • Administrators/managers can track compliance more easily Tassonomia delle UC
  • 97. 8. Eccessiva dipendenza dalla tecnologia – l‟affidarsi quotidianamente alle funzionalità di un sistema informatico può essere pericoloso qualora quel sistema non funzionasse per un certo periodo di tempo, soprattutto se procedure alternative e modalità manuali o basate su strumenti cartacei sono state nel frattempo dimenticate o non sono comunque padroneggiate con la confidenza necessaria a non produrre (più) errori. – «Overdependence», distinguiamo tra • «overconfidence» – ...nei dati, ...nelle funzionalità; (ricordarsi «garbage in-garbage out») • «overreliance» – Senza l‟IT non si lavora altrettanto bene o non si lavora affatto. Tassonomia delle UC
  • 98. • Persistenza dell'uso della carta – la carta, per le sue caratteristiche di flessibilità,annotabilità e informalità, può affiancare o sostituire almeno parzialmente pratiche documentali informatizzate; così facendo, però, i supporti cartacei possono introdurre replicazione di dati (non sincronizzazione), e noti problemi di leggibilità e località delle informazioni. Tassonomia delle UC Dykstra, R. H., Ash, et al. (2009). Persistent paper: the myth of “going paperless”. In AMIA Annual Symposium Proceedings (Vol. 2009, p. 158). American Medical Informatics Association.
  • 99. Questa tassonomia è stata tradotta in un breve questionario, somministrato a quasi 176 ospedali per capire: la rilevanza/prevalenza assoluta (percepita) di ciascuna categoria nel proprio workplace – in una scala da 1 a 6 a d esempio la classifica di rilevanza/prevalenza – ad esempio tramite la «media» o il calcolo dei ranking. Tassonomia delle UC Ash, J. S., et al.(2007). The extent and importance of unintended consequences related to computerized provider order entry. Journal of the American Medical Informatics Association, 14(4), 415-423.
  • 100. Le categorie considerate più “importanti” sono state: * continue richieste evolutive * problemi legati alle modalità di comunicazione * problemi legati al flusso di lavoro Le categorie (percepite come°°) meno rilevanti: * cambiamenti nella struttura di potere * introduzione di nuovi errori. Gli autori rilevano che non c‟è correlazione tra quanto tempo una HIT è in uso e le unintended consequences riscontrate («il tempo non rimargina le ferite») Tassonomia delle UC °° da chi?
  • 101. Un semplice questionario
  • 102. • Possiamo chiederci se un progetto ICT (in un contesto ospedaliero, IT, e non) ha avuto o sta avendo successo? • Se vogliamo chiedercelo, come possiamo impostare l‟analisi? Evaluation
  • 103. • Possiamo chiederci se un progetto ICT (in un contesto ospedaliero, IT, e non) ha avuto o sta avendo successo? • Che cos‟è il successo di un progetto HIT? Evaluation
  • 104. • Possiamo chiederci se un progetto ICT (in un contesto ospedaliero, IT, e non) ha avuto o sta avendo successo? • Che cos‟è il successo di un progetto HIT? – Dipende dagli obiettivi (che si volevano raggiungere e che hanno giustificato l‟investimento) – Dipende dagli stakeholder, e dalle loro aspettative. – Dipende quindi anche dal contesto tecnologico e culturale. – Dipende anche da quando lo si valuta e “misura”… Evaluation
  • 105. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?)
  • 106. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Incremento di produttività (Bailey&Pearson, 83) Efficacia organizzativa (Ives, 83) Impatto (net benefit)
  • 107. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Incremento di produttività (Bailey&Pearson, 83) Efficacia organizzativa (Ives, 83) Impatto (net benefit) se il sistema è volontario USAGE se il sistema è mandatorio (use is not an option) ACCEPTANCE * Goodhue, D. L., & Thompson, R. L. (1995). Task-technology fit and individual performance. MIS quarterly, 213-236. *
  • 108. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?)
  • 109. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Chi dice che il successo è legato all‟uso e all‟utente?
  • 110. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Chi dice che il successo è legato all‟uso e all‟utente? “… la sensibilità e il giudizio di coloro che ne hanno fatto esperienza” John Stuart Mill, 1861
  • 111. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Chi dice che il successo è legato all‟uso e all‟utente? “… to fall back on the verdict […] of experience of all those capable of enjoying [it]” John Stuart Mill, 1861
  • 112. Evaluation SUCCESS Productivity (& Performance?) User Adoption (& Satisfaction?) Chi dice che il successo è legato all‟uso e all‟utente?
  • 113. Evaluation 1992 Information Success Model (DeLone WH, McLean E) DeLone WH, McLean E: Information systems success: the quest for the dependent variable. Inform Systems Res 1992, 3(1):60-95
  • 114. Evaluation Modello basato su una visione a processo (Shannon & Weaver 1949) e di natura causale (flusso da sx a dx). La variabile dipendente è l’impatto. 1992
  • 115. Evaluation Riformulato nel 2002 per recepire i contributi di più di 150 altri lavori nello stesso ambito 2002 Delone, W. H. (2003). The DeLone and McLean model of information systems success: a ten-year update. Journal of management information systems, 19(4), 9-30.
  • 116. Evaluation Usato recentemente anche in ambito RIS/PACS… 2002 2010 Paré G, Lepanto L, Aubry D, Sicotte C: Toward a multidimensional assessment of picture archiving and communication system success. Int J Technol Assess Health Care 21 (4):471–479, 2005
  • 117. Evaluation Notate l’affinità con l’NPS promosso da Reichheld nel 2003 2002 2010 Reichheld, F. F. (2003). The one number you need to grow. Harvard business review, 81(12), 46-55.
  • 118. Evaluation Legenda: A: costrutto, dmensione, un concetto che è oggetto di indagine per mezzo di un insieme di domande (items) fortemente correlate (alpha di Cronbach). C: archi che rappresentano una relazione di “influenza” (ipotizzata) o dipendenza. B: solitamente R2 misura della correlazione tra la “variabile” a dx (ind.) e quella a sx (dip.). D: Grado di significatività (solitamente *=>P<0.05; **=>P<0.01; ***=>P<0.001), con P probabilità che la influenza NON esista, cioè che H0 sia vera date le risposte raccolte) E: relazione di influenza che non era stata ipotizzata, ma è risultata significativa. A B BB C D E
  • 119. Evaluation ISM: ha il merito di suggerire che il “successo” è un processo, non uno stato, un costrutto multidimensionale che scaturisce dall’interazione di più fattori. Vale sia per sistemi volontari (use), che per sistemi mandatori (user satisfaction). 2002 2010
  • 120. Evaluation Però presenta il limite di considerare qualità (di sistema e di informazione) intese come “intrinseche”, indipendenti dal contesto. Non spiega il fenomeno di sistemi che hanno successo in un workplace e falliscono in un altro. 2002 2010
  • 121. Evaluation Original Technology Acceptance Model (TAM) by Davis (1989)
  • 122. Evaluation Introdotto per prevedere/misurare l’attitudine (e l’uso reale) del sistema. Entrambi i fattori dipendono dalle caratteristiche del sistema. Validato solo per uso volontario.
  • 123. Evaluation Intenzione ad usare la tecnologia Uso effettivo della tecnologia Reazioni individuali all‟uso della tecnologia
  • 124. Evaluation Base di partenza di innumerevoli modelli di acceptance (e.g., Information Technology Adoption Model - ITAM, Dixon 1999; TAM2, Venkatesh & Davis 2000; Unified Theory of Acceptance and Use of Technology - UTAUT, Venkatesh et al. 2003), che si concentrano tutti sull’influenza di attributi individuali (abilità, competenze, …) e del sistema (funzionalità, qualità, …).
  • 125. Evaluation L’UTAUT, (Venkatesh et al. 2003), è il più “maturo” ed è usato anche usato in ambito radiologico (Duyck, 2010).
  • 126. Evaluation
  • 127. Evaluation Dixon nel 1999 ha introdotto il concetto di FIT tra user e system, che è stato esteso a quello di FIT tra sistema e task (task-individual-technology) da Goodhue (2000): il Task-Technology-Fit model (TTF). Goodhue DL, Klein BD, March ST: User evaluations of IS as surrogates for objective performance. Inform & Manage 2000, 38:87-101.
  • 128. Evaluation Misura l’influenza delle abilità individuali, caratteristiche della tecnologia e requisiti dei task (supportati dalla tecnologia) su performance e user evaluation, sottolineando l'importanza dell0interazione (fit) tra queste tre componenti.
  • 129. Evaluation Integrated TAM/TTF Model (Dishaw and Strong 1999)
  • 130. Evaluation FITT framework ("Fit between Individuals, Task and Technology") Ammenwerth, E., Iller, C., & Mahler, C. (2006). IT-adoption and the interaction of task, technology and individuals: a fit framework and a case study. BMC Medical Informatics and Decision Making, 6(1), 3.
  • 131. Evaluation Interessante per l’idea che si debba valutare il FIT dopo averlo “pianificato” e in qualche modo “realizzato”.
  • 132. Evaluation
  • 133. Evaluation Vediamo più in dettaglio che items sono dentro ciascuna dimensione… 2002 2010 Paré G, Lepanto L, Aubry D, Sicotte C: Toward a multidimensional assessment of picture archiving and communication system success. Int J Technol Assess Health Care 21 (4):471–479, 2005
  • 134. Evaluation Paré G, Lepanto L, Aubry D, Sicotte C: Toward a multidimensional assessment of picture archiving and communication system success. Int J Technol Assess Health Care 21 (4):471–479, 2005 Ease of use Generally speaking, the PACS system is easy to use. It is easy to master PACS system functionalities. The graphical interfaces of PACS are clear and easy to understand. It is easy to find images from the other facilities in PACS.a It is easy to send images and information to other facilities using PACS. Screen quality The PC screens available in our facility are of acceptable quality. The specialized PACS screens are of acceptable quality. The quality of the screens encourage me to use PACS. PACS-RIS integration The PACS/RIS subsystems are well integrated. The PACS/RIS/Dictation subsystems are well integrated. Joint use of PACS/RIS/Dictation makes the work easier. When the data on a patient comes from different facilities, the PACS/RIS systems provide well-integrated information When the data on a patient comes from different facilities, the PACS/RIS/Dictation systems provide well-integrated information
  • 135. Evaluation Paré G, Lepanto L, Aubry D, Sicotte C: Toward a multidimensional assessment of picture archiving and communication system success. Int J Technol Assess Health Care 21 (4):471–479, 2005 Reliability PACS is rarely offline because of technology breakdowns. Unexpected PACS service outages rarely occur. PACS use is uninterrupted because the system is bug-free. Accessibility We have a sufficient number of PACS work stations. I have rarely had to wait for access to a work station in order to consult PACS. I have easy access to PACS from my home computer. Response time I have the impression that images download quickly. We have quick access to images from other facilities. With the exception of image management, PACS responds quickly. Perceived usefulness Overall, PACS provides a complete range of functionalities that support my work as a professional. My clinical practices are very well harmonized with PACS. Using PACS is compatible with all aspects of my tasks.
  • 136. Evaluation Data quality The PACS images produced locally in your facility (or externally) are: Complete Reliable and precise Well organized and carefully presented Available in a timely manner Secure and confidential Quality of technical support The staff in your hospital who provide technical assistance for PACS Are easy to reach Provide quick service Are competent Pay attention to user needs Are able to find satisfactory solutions Use I often use the PACS system to fulfill my functions. I use the PACS system for the great majority of my clientele. I use a wide range of the PACS system’s functionalities. I often use the PACS system to obtain clinical data from other facilities.
  • 137. Evaluation Overall satisfaction Overall, my experience using the PACS system has been satisfactory. I enjoy using the PACS system in my work. Overall, using PACS is more satisfying than using the old system. Productivity My personal productivity has improved since I have been using the PACS. Using PACS allows me to save time. Using PACS has saved me some of the time I used to spend moving about. The work load has increased due to the greater number of requests for medical imaging examinations, particularly those originating outside my facility. Quality of services When compared to the use of photographic films, our use of PACS has improved quality of care. Use of PACS has improved the quality of medical imaging diagnoses. PACS has reduced the time between examination requests and the delivery of results. PACS use has led to improved relations between professionals.
  • 138. Evaluation Inter-hospital access PACS has made medical imaging services more accessible. Regional PACS has reduced waiting times for patients in my region. The PACS system has reduced patient transfers between facilities. PACS has reduced the impact of staffing shortages in medical imaging. Confirmation of expectations My personal experience with PACS is better than I had expected. Generally speaking, the benefits of PACS are in line with my initial expectations. The ease of access to images from other facilities is better than what I had initially hoped. Intended future use I want to continue using the PACS system in my clinical activities. I want to continue using PACS to obtain imaging data from other facilities.a If I could, I would like to become more proficient at using the PACS system. Even more: Would you be happy to move to another Radiology Department where the same RIS/PACS is adopted? Would you recommend such a RIS/PACS to a colleague of yours? (cf. the NPS)
  • 139. CONOSCENZE PREGRESSE mediana moda media
  • 140. CONOSCENZE PREGRESSE
  • 141. Requirement Elicitation • Requirement… una proprietà che il sistema deve esibire/possedere per avere successo nell'ambiente in cui sarà usato. Joseph A. Goguen. 1994. Requirements engineering as the reconciliation of social and technical issues. In Requirements engineering, Marina Jirotka and Joseph A. Goguen (Eds.). Academic Press Professional, Inc., San Diego, CA, USA 165-199
  • 142. Requirement Elicitation • Requirement… una proprietà che il sistema deve esibire/possedere per avere successo nell'ambiente in cui sarà usato. aiutare l‟utente a raggiungere i «suoi» obiettivi (stakeholder) Joseph A. Goguen. 1994. Requirements engineering as the reconciliation of social and technical issues. In Requirements engineering, Marina Jirotka and Joseph A. Goguen (Eds.). Academic Press Professional, Inc., San Diego, CA, USA 165-199
  • 143. Requirement Elicitation • …elicitation…
  • 144. Requirement Elicitation • “Elicitare requisiti” significa quindi – rappresentare esplicitamente (solitamente per iscritto e in linguaggio tecnico), e possibilmente in maniera non ambigua, ciò che “è richiesto” (da qualcuno) che un sistema computazionale faccia perché qualcuno raggiunga un qualche obiettivo.
  • 145. Requirement Elicitation • “Elicitare requisiti” come? – introspezione • Del requirement engineer? Del requirement analyst? Dell‟esperto di dominio interpellato? Del committente? – questionari (scritti e/o come base per interviste semistrutturate) – protocol analysis – osservazioni (anche video) e loro analisi – interviste informali/open-ended e analisi del contenuto – Studio degli artefatti tradizionali / documentazione corrente / uso sistemi legacy
  • 146. Requirement Elicitation • “Elicitare requisiti” come? – introspezione • Del requirement engineer? Del requirement analyst? Dell‟esperto di dominio interpellato? Del committente? – questionari (scritti e/o come base per interviste semistrutturate) – protocol analysis – osservazioni (anche video) e loro analisi – interviste informali/open-ended e analisi del contenuto – Studio degli artefatti tradizionali / documentazione corrente / uso sistemi legacy Etnometodologia/etnografia
  • 147. Requirement Elicitation • “Elicitare requisiti” – L‟importanza dello zooming e della “geometria variabile” dal RE alla Etnometodologia (Goguen) – In poche parole è il risultato di un‟opera sia di disvelamento, che di evocazione, alla luce degli obiettivi di “qualcuno” e dei suoi “bisogni”.
  • 148. Requirement Elicitation
  • 149. Requirement Elicitation Prima gli obiettivi! OK, parliamo allora di funzionalità Il processo di appropriazione è impredicibile
  • 150. Requirement Elicitation Brittan, J.N. (1980) Design for a changing environment. The Computer Journal. 23(1):13-19
  • 151. Requirement Elicitation
  • 152. Requirement Elicitation
  • 153. Le tre vignette ci parlano (tacitamente) meglio di molti trattati e articoli scientifici del perché i progetti ICT falliscono 1. ...perché ciascuna categoria di attore introduce un suo errore nel mettere a fuoco il sistema finale: – L‟errore che sa fare meglio… 2. ...perché l‟Utente non sempre sa spiegare bene quello che vuole e perché nel corso del progetto solitamente sviluppa aspettative sempre crescenti verso il prodotto (per cui aspetta così tanto). 3. ...perché sentiti vari utenti (una eccezione ed un lusso anche oggi), ciascuno di essi descriverà la sua visione del sistema/processo, omettendo dettagli importanti inconsapevolmente (perché davvero esperto del dominio) o consapevolmente (perché non tutto può essere detto esplicitamente, o la practica è più “sporca” della teoria). Requirement Elicitation
  • 154. • La prima sfida è trovare e parlare con gli “esperti di dominio”. Esperto: – una persona che ha fatto un lavoro per (almeno) 10000 ore (K.Anders Ericsson, 2007 e Malcolm Gladwell, 2008) – una persona che riconosce un errore dopo averlo commesso. (~Bohr) – una persona che sa così bene (come si fa) una cosa che fa fatica ad esprimerlo a parole (cf.“tacit knowledge”) – Noi lo vogliamo anche ”utente” nel sistema sociotecnico e utente della tecnologia che verrà. Requirement Elicitation
  • 155. • La seconda sfida è esprimere quello che gli utenti hanno bisogno che sia automatizzato : – Un requisito è richiesto. – Un bisogno (need) è sentito. – Una necessità è ciò di cui si necessita per fare una cosa (anche inconscamente). Requirement Elicitation
  • 156. • La seconda sfida è esprimere quello che gli utenti hanno bisogno che sia automatizzato : – Un requisito è richiesto. – Un bisogno (need) è sentito. – Una necessità è ciò di cui si necessita per fare una cosa (anche inconscamente). Requirement Elicitation Requirement è sia la cosa richiesta, che la cosa di cui si ha bisogno, consciamente percepita. Ma spesso l‟utente non sa esattamente cosa vuole e di cosa ha bisogno…
  • 157. • Noi vediamo un modo per esprimere e caratterizzare “requisiti” per quanto possibile non ambigui (…se c‟è un glossario è meglio). non inconsistenti (… i conflitti non sono innominabili) facilmente accessibili in una documentazione di continuo riferimento e che evolve con continuità (cf. feedback). Requirement Elicitation
  • 158. Requirement Elicitation www.volere.co.uk/
  • 159. Requirement Elicitation
  • 160. Requirement Elicitation
  • 161. 1. Requisiti funzionali: requisiti relativi a ciò che il sistema fa ovvero alle capacità che il sistema fornisce ai suoi utenti per supportarli nel raggiungere i loro obiettivi. 2. Requisiti non funzionali: in generale, requisiti relativi non a ciò che il sistema fa, ma al “come”. Per raffinamenti successivi si suole distinguere tra: Requirement Elicitation
  • 162. 1. Requisiti funzionali: requisiti relativi a ciò che il sistema fa ovvero alle capacità che il sistema fornisce ai suoi utenti per supportarli nel raggiungere i loro obiettivi. 2. Requisiti non funzionali: in generale, requisiti relativi non a ciò che il sistema fa, ma al “come”. Per raffinamenti successivi si suole distinguere tra: Requisiti di utilizzo: Requisiti interazionali: requisiti che riguardano una modalità ritenuta opportuna di interazione con il sistema nello specifico contesto di lavoro. Requisiti di usabilità: quanto deve essere semplice accedere ad una certa funzionalità (descritta da un requisito funzionale). Requisiti Tecnologici/Architetturali: quali tecnologie devono essere impiegate, quali compatibilità devono essere garantite, che struttura deve avere l'architettura del sistema, etc. Requisiti di manutenibilità: quanto deve essere facile individuare, isolare e risolvere eventuali difetti. Requisiti di estendibilità: quanto deve essere facile estendere o migliorare una certa funzionalità). Requisiti di scalabilità : quanto il sistema deve poter supportare un numero crescente di utenti e di dati nel tempo rispetto a quelli inizialmente concepiti; Requisiti di affidabilità : quanto deve essere probabile che il sistema fornisca ogni volta una risposta corretta o esatta; Requisiti di performance : di velocità (quanto deve essere veloce il sistema ad erogare i servizi richiestigli) e di capacità (quanti utenti il sistema può supportare e quanti dati può gestire). Requisiti di sicurezza : quali requisiti la piattaforma deve garantire in termini di sicurezza, reliability, dependability e privacy dei dati; ognuno di questi concetti può ovviamente essere declinato in termini di altre categorie parzialmente sovrapposte. Requisiti temporali (date di rilascio o completamento fasi). Etc… Requirement Elicitation
  • 163. Requirement Elicitation
  • 164. Requirement Elicitation
  • 165. • Il singolo requisito deve essere espresso in termini di un comportamento elementare che il sistema informatico manifesta per offrire ai suoi utenti la funzionalità/proprietà necessaria; • esso è espresso in una forma neutra che prevede il sistema informatico come soggetto di un predicato verbale oppure di una forma verbale coniugata o al tempo presente indicativo o al tempo al futuro: a esempio,“il sistema permette (all'utente)… in tutte le occasioni che…”,“il sistema stamperà… quando l‟utente…”. • Verbi modali possono suggerire una priorità, ad esempio: – Dovrà (need), farà (must), potrà (wish) Requirement Elicitation
  • 166. Requirement Elicitation
  • 167. Requirement Elicitation
  • 168. Requirement Elicitation
  • 169. Requirement Elicitation
  • 170. Requirement Elicitation
  • 171. Requirement Elicitation
  • 172. Requirement Elicitation * In una scala ordinale (es.: da 1 a 6) quanto vantaggio (benefit) risulterebbe se la soluzione che soddisfa (fit) questo requisito fosse disponibile? * In una scala ordinale (es.: da 1 a 6) quanto svantaggio (damage) risulterebbe se la soluzione che soddisfa (fit) questo requisito NON fosse disponibile?
  • 173. Requirement Elicitation
  • 174. • Di solito si prevedono tre livelli di priorità 1. Need: Caratterizza un requisito considerato necessario e imprescindibile per garantire l‟operatività (corrisponde alla espressione informale “ne ho bisogno e non posso farne a meno”). Un need è considerato un requisito “essenziale”, cioè un requisito la cui non soddisfazione da parte del sistema costituisce motivo sufficiente per rendere il sistema inaccettabile. 2. Must: Caratterizza un requisito funzionale volto a soddisfare una esigenza operativa (corrisponde alla espressione informale “ne ho bisogno e non voglio farne a meno”). Un must può essere sia “essenziale” che “condizionale”; in quest‟ultimo caso, la sua non soddisfazione non costituisce condizione sufficiente per rendere il sistema inaccettabile. 1. Wish: Caratterizza un requisito che probabilmente contribuisce a rendere il sistema ottimale (corrisponde alla espressione informale “non ne ho bisogno ma mi piacerebbe averlo”). Un wish è considerato un requisito opzionale, nel senso che la sua soddisfazione (o meno) non influenza il grado di accettabilità del sistema ma solo il suo livello di ottimalità. Requirement Elicitation
  • 175. • Perché si prevedono livelli di priorità? • Perché l‟ «ottimo è nemico del bene», cioè: Bisogna aspettarsi che nel budget disponibile, o nel tempo previsto, non si riuscirà ad avere tutto, Bisogna quindi capire su quali requisiti concentrarsi perché «a regime» gli utenti abbiano a disposizione funzionalità soddisfacenti, di «successo», ... Requirement Elicitation
  • 176. • OK, allora come assegniamo un requisito ad una classe di priorità. 1. Introspection – Dell‟analista, dell‟esperto di dominio – Su base quantitativa (economica) o soggettiva 2. Interviste – Con uno o – più esperti di dominio • (separatamente e in Focus Group, con o senza Metodo Delphi) 3. Questionari a scale ordinali (più utenti finali ed esperti) – Assegnamento diretto (adeguato solo per pochi requisiti) – Assegnamento indiretto • Media per ciascun requisito e ranking per ordine descrescente, poi categorizzazione. • Ranking per ciascun rispondente, poi ranking globale sulla base della media dei singoli ranking. Requirement Elicitation
  • 177. Dato questo elenco di funzionalità innovative: 1) Segnalazione automatica degli slot liberi che ottimizzano l'uso delle modalità, segnalazione dei conflitti di worklist. 2) Segnalazione automatica di condizioni importanti (ad es.: allergie a tipi di contrasto e gravidanza) o eventi notevoli (dosaggi elevati). 3) Popolamento automatico del referto con informazioni prese dalla documentazione di prescrizione (anagrafica, sintomi, tipo di esame). 4) Modelli di refertazione predefiniti importabili e riutilizzabili in base al tipo di esame e diagnosi formulata. 5) Riconoscimento vocale dei comandi e del contenuto dei referti (Dragon). 6) Possibilità di annotare liberamente l'immagine o parti del video con testo, figure poligonali, icone predefinite, tratti mano libera, riferimenti (hyperlink) ad altre immagini o documenti e di allegare le annotazioni create in referto. 7) Possibilità di misurare parti dell'immagine. 8) Componente di messaggistica istantanea (chat). 9) Accesso via Web a referti e immagini, sia per i radiologi che per il medico prescrittore (e.s.: ortopedico). 10) Disponibilità di un fascicolo paziente in cui trovare tutti gli esami precedenti e ulteriore documentazione. ...coinvolgere una dozzina di esperti di dominio e capire quali sono le funzionalià considerate più utili... ... e scegliere il sistema che ottimizzerebbe anche la soddisfazione. Esercizio di prioritizzazione
  • 178. Le vostre risposte (fine aprile 2013): La scala ordinale può essere fortemente «customizzata» (ad es.: da 1 a 5, da 1 a 6, da 1 a 7, da 1 a 10; con etichette esplicite, o solo agli estremi, oVAS; relativa ad importanza, benefici attesi, o altro), l‟importante è che i valori associati alle risposte vadano da 1 (il buono) a n (il non buono). Esercizio di prioritizzazione
  • 179. Ragionare per colonne E‟ possibile calcolare indici di tendenza centrale, ma diffidate della media: non ha senso! ...a meno che non crediate che la differenza tra „abbastanza importante‟ e „importante‟ sia la stessa tra „importante‟ e „molto importante‟... Il suggerimento migliore è: non prendete quei numeri per dei... numeri! Esercizio di prioritizzazione
  • 180. Ragionare per colonne E‟ possibile calcolare indici di tendenza centrale, ma diffidate della media: non ha senso! (paradossalmente la deviazione standard è più espressiva!) ...a meno che non crediate che la differenza tra „abbastanza importante‟ e „importante‟ sia la stessa tra „importante‟ e „molto importante‟... Il suggerimento migliore è: non prendete quei numeri per dei... numeri! Esercizio di prioritizzazione
  • 181. Ragionare per colonne E‟ possibile calcolare indici di tendenza centrale, ma diffidate della media: non ha senso! (paradossalmente la deviazione standard è più espressiva!) ...a meno che non crediate che la differenza tra „abbastanza importante‟ e „importante‟ sia la stessa tra „importante‟ e „molto importante‟... Il suggerimento migliore è: non prendete quei numeri per dei... numeri! Esercizio di prioritizzazione Inoltre una ANOVA ci può dire se le risposte sono date a “caso” e non ci sono differenze sensibili tra le colonne…
  • 182. Ragionare per righe, cioè per utente! Ogni rispondente assegna ad ogni funzionalità una categoria di valore. E‟ possibile quindi capire le sue preferenze indirettamente. Esercizio di prioritizzazione
  • 183. Ragionare per righe Ogni rispondente assegna ad ogni funzionalità una categoria di valore. E‟ possibile quindi capire le sue preferenze indirettamente. A questa persona piacciono più o meno tutte le funzionalità, ma la seconda, la quinta e la nona di più della prima, della sesta, della settima e della decima, e queste ultime più delle funzionalità rimanenti... Esercizio di prioritizzazione 2 1 3 3 1 2 2 3 1 2
  • 184. Ragionare per righe Se lo fate per tutti, potete capire quali funzionalità piacciono di più, rispetto a tutte le altre. Per farlo in fretta potete usare un programma che ho scritto io, lanciandolo sui dati riportati nella prossima pagina. Analizziamone il risultato. Esercizio di prioritizzazione
  • 185. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8.
  • 186. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8.
  • 187. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. 10 Disponibilità di un fascicolo paziente in cui trovare tutti gli esami precedenti e ulteriore documentazione. 7 Possibilità di misurare parti dell'immagine. 9 Accesso via Web a referti e immagini, sia per i radiologi che per il medico prescrittore (e.s.: ortopedico). 2 Segnalazione automatica di condizioni importanti (ad es.: allergie a tipi di contrasto e gravidanza) o eventi notevoli (dosaggi elevati). 1 Segnalazione automatica degli slot liberi che ottimizzano l'uso delle modalità, segnalazione dei conflitti di worklist. 5 Riconoscimento vocale dei comandi e del contenuto dei referti (Dragon). 6 Possibilità di annotare liberamente l'immagine o parti del video con testo, figure poligonali, icone predefinite, tratti mano libera, riferimenti (hyperlink) ad altre immagini o documenti e di allegare le annotazioni create in referto. 3 Popolamento automatico del referto con informazioni prese dalla documentazione di prescrizione (anagrafica, sintomi, tipo di esame). 4 Modelli di refertazione predefiniti importabili e riutilizzabili in base al tipo di esame e diagnosi formulata. 8 Componente di messaggistica istantanea (chat).
  • 188. Esercizio di prioritizzazione ####################### ## DETAILED REPORT ## Element 1 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 2.4615, P-value: 0.2921 on input [7, 3, 3]. The association is not statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 8.8571, P-value: 0.0119 on input [6, 1, 0]. The association is statistically significant. Element 2 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 15.8462, P-value: 0.0004 on input [11, 0, 2]. The association is highly statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 11.6364, P-value: 0.0030 on input [9, 1, 1]. The association is highly statistically significant. Element 3 is associated with priority level 3. Analysis of uniformity bwt rank levels. Chi Square: 7.5385, P-value: 0.0231 on input [5, 0, 8]. The association is statistically significant. […]
  • 189. Esercizio di prioritizzazione ####################### ## DETAILED REPORT ## Element 1 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 2.4615, P-value: 0.2921 on input [7, 3, 3]. The association is not statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 8.8571, P-value: 0.0119 on input [6, 1, 0]. The association is statistically significant. Element 2 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 15.8462, P-value: 0.0004 on input [11, 0, 2]. The association is highly statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 11.6364, P-value: 0.0030 on input [9, 1, 1]. The association is highly statistically significant. Element 3 is associated with priority level 3. Analysis of uniformity bwt rank levels. Chi Square: 7.5385, P-value: 0.0231 on input [5, 0, 8]. The association is statistically significant. […]
  • 190. Esercizio di prioritizzazione ####################### ## DETAILED REPORT ## […] Element 4 is associated with priority level 3. Analysis of uniformity bwt rank levels. Chi Square: 7.5385, P-value: 0.0231 on input [2, 2, 9]. The association is statistically significant. Element 5 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 1.0769, P-value: 0.5836 on input [6, 3, 4]. The association is not statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 3.0000, P-value: 0.2231 on input [4, 1, 1]. The association is not statistically significant. Element 6 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 1.0769, P-value: 0.5836 on input [6, 3, 4]. The association is not statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 1.0000, P-value: 0.6065 on input [3, 2, 1]. The association is not statistically significant. […]
  • 191. Esercizio di prioritizzazione ####################### ## DETAILED REPORT ## […] Element 7 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 15.8462, P-value: 0.0004 on input [11, 2, 0]. The association is highly statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 7.8182, P-value: 0.0201 on input [8, 2, 1]. The association is statistically significant. Element 8 is associated with priority level 3. Analysis of uniformity bwt rank levels. Chi Square: 12.1538, P-value: 0.0023 on input [3, 0, 10]. The association is highly statistically significant. Element 9 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 11.2308, P-value: 0.0036 on input [10, 2, 1]. The association is highly statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 10.4000, P-value: 0.0055 on input [8, 2, 0]. The association is highly statistically significant.
  • 192. Esercizio di prioritizzazione ####################### ## DETAILED REPORT ## […] Element 10 is associated with priority level 1. Analysis of uniformity bwt rank levels. Chi Square: 20.4615, P-value: 0.0000 on input [12, 1, 0]. The association is highly statistically significant. within the first priority level, the mode position is 1. Analysis of uniformity bwt ranks. Chi Square: 13.5000, P-value: 0.0012 on input [10, 1, 1]. The association is highly statistically significant.
  • 193. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. high ** high ** high ** high ** high § high § high § low * low * low ** 10 Disponibilità di un fascicolo paziente in cui trovare tutti gli esami precedenti e ulteriore documentazione. 7 Possibilità di misurare parti dell'immagine. 9 Accesso via Web a referti e immagini, sia per i radiologi che per il medico prescrittore (e.s.: ortopedico). 2 Segnalazione automatica di condizioni importanti (ad es.: allergie a tipi di contrasto e gravidanza) o eventi notevoli (dosaggi elevati). 1 Segnalazione automatica degli slot liberi che ottimizzano l'uso delle modalità, segnalazione dei conflitti di worklist. 5 Riconoscimento vocale dei comandi e del contenuto dei referti (Dragon). 6 Possibilità di annotare liberamente l'immagine o parti del video con testo, figure poligonali, icone predefinite, tratti mano libera, riferimenti (hyperlink) ad altre immagini o documenti e di allegare le annotazioni create in referto. 3 Popolamento automatico del referto con informazioni prese dalla documentazione di prescrizione (anagrafica, sintomi, tipo di esame). 4 Modelli di refertazione predefiniti importabili e riutilizzabili in base al tipo di esame e diagnosi formulata. 8 Componente di messaggistica istantanea (chat).
  • 194. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. high ** high ** high ** high ** high § high § high § low * low * low ** 10 Disponibilità di un fascicolo paziente in cui trovare tutti gli esami precedenti e ulteriore documentazione. 7 Possibilità di misurare parti dell'immagine. 9 Accesso via Web a referti e immagini, sia per i radiologi che per il medico prescrittore (e.s.: ortopedico). 2 Segnalazione automatica di condizioni importanti (ad es.: allergie a tipi di contrasto e gravidanza) o eventi notevoli (dosaggi elevati). 1 Segnalazione automatica degli slot liberi che ottimizzano l'uso delle modalità, segnalazione dei conflitti di worklist. 5 Riconoscimento vocale dei comandi e del contenuto dei referti (Dragon). 6 Possibilità di annotare liberamente l'immagine o parti del video con testo, figure poligonali, icone predefinite, tratti mano libera, riferimenti (hyperlink) ad altre immagini o documenti e di allegare le annotazioni create in referto. 3 Popolamento automatico del referto con informazioni prese dalla documentazione di prescrizione (anagrafica, sintomi, tipo di esame). 4 Modelli di refertazione predefiniti importabili e riutilizzabili in base al tipo di esame e diagnosi formulata. 8 Componente di messaggistica istantanea (chat).
  • 195. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. Si possono fare altre valutazioni; e.g., codificare le funzionalità (attraverso il calcolo dell‟interrater agreement): “refertazione”,“pianificazione”, “collaborazione”, etc. e vedere quali aree sono più omogenee (R2) e quali sono le più importanti…
  • 196. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. …oppure eseguire una sotto- prioritizzazione all‟interno di una fascia di priorità, o rifacendo la rilevazione, o con il calcolo del Chi Quadro (vedi report).
  • 197. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. Infine si noti che la stessa tecnica per la prioritizzazione di funzionalità future può essere impiegata per valutare funzionalità/aspetti attuali, già in uso, e valutare quali siano le «peggiori», cioè quelle che devono essere migliorate (cioè per identificazione aree di miglioramento):
  • 198. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. 3 Popolamento automatico del referto con informazioni prese dalla documentazione di prescrizione (anagrafica, sintomi, tipo di esame). 4 Modelli di refertazione predefiniti importabili e riutilizzabili in base al tipo di esame e diagnosi formulata. 8 Componente di messaggistica istantanea (chat). Immaginiamo cioè che le funzionaltà identificate a sx siano già adottate. I punti 3 e 4 ci farebbero capire che ci sono problemi con la refertazione semi- automatica; e che la «chat» (punto 8) non è sfruttata al pieno delle sue potenzialità.
  • 199. Esercizio di prioritizzazione #### ANALYSIS REPORT #### ########################## Number of respondents involved: 13. Sum of rankings for each element considered: [46, 31, 74, 87, 55, 59, 25, 93, 29, 19] Average position for each element considered: [3.54, 2.38, 5.69, 6.69, 4.23, 4.54, 1.92, 7.15, 2.23, 1.46] ############### ## RANKING ## 1 :: Element 10. 2 :: Element 7. 3 :: Element 9. 4 :: Element 2. 5 :: Element 1. 6 :: Element 5. 7 :: Element 6. 8 :: Element 3. 9 :: Element 4. 10 :: Element 8. 8 Componente di messaggistica istantanea (chat). In particolare la «chat» (punto 8) è considerata a bassa utilità ma non con alta significatività statistica. Lo si verifica facendo un «1 Sample Sign Test for Median»* - sull‟ipotesi nulla che la mediana per quella categoria sia minore o uguale a 4 (in una scala tra 1 – buono e 6 cattivo) e vedendo se P < 0.05 oppure no. *: http://www.fon.hum.uva.nl/Service/Statistics/Sign_Test.html
  • 200. /dipendenze Requirement Elicitation
  • 201. Dipendenze / conflitti Ogni requisito deve essere atomico, ovvero deve essere espresso in termini di un comportamento elementare del sistema («il sistema fa...», «il sistema permette di...»). Nel caso in cui emergano dei bisogni legati a comportamenti «compositi», si definiscano più requisiti e li si «colleghi» attraverso il campo «dipendenze/conflitti » eventualmente descrivendo il tipo di dipendenza/legame in formato «libero». Conoscere il legame tra diversi requisiti è importante in quanto facilita il «change management» (es:A è legato a B, se cambio qualcosa in A valuto se è necessario cambiare anche B, ...)
  • 202. Requirement Elicitation
  • 203. Requirement Elicitation
  • 204. Cosa può andare storto? Dopo tutto si tratta solo di scrivere cose sensate… Requirement Elicitation
  • 205. Cosa può andare storto? Dopo tutto si tratta solo di scrivere cose sensate… Requirement Elicitation The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. [Brooks, Frederick P. Jr. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 10-19,April 1987., p. 17]
  • 206. Cosa può andare storto? Limitiamoci agli errori più comuni Requirement Elicitation
  • 207. Il Therac-25 è stata una macchina per curare tramite la radioterapia, prodotta dalla AECL come succeditrice alle unità Therac-6 e Therac-20, prodotte inizialmente insieme alla francese Compagnie Generale de Radiologie. Questa macchina è stata causa di almeno sei incidenti avvenuti tra il 1985 e il 1987 La macchina offriva due metodi per la radioterapia: Terapia a base di fasci di elettroni, che erogava una bassa dose di elettroni ad alta energia (da 5 MeV a 25 MeV) per poco tempo; Terapia a base di raggi X ad alta energia, che erogava raggi X tramite il bombardamento di un "bersaglio" con un fascio di elettroni da 25Mev. A seguito di lamentele, la AECL consentì, per il Therac-25, di ricopiare i dati che comparivano nella colonna "PRESCRIBED" nella colonna "ACTUAL" semplicemente premendo il pulsante di "carriage return", rendendo vano il controllo. Quando la macchina era impostata per erogare elettroni, veniva erogato un fascio di elettroni a bassa energia, poi indirizzati e diffusi tramite dei magneti di guida ed un diffusore. Il fascio di elettroni ad alta potenza colpiva i pazienti con una dose 100 volte superiore a quella desiderata, causando una sensazione descritta come "un'intensa scossa elettrica", di conseguenza alcuni pazienti urlavano e scappavano dalla stanza.Alcuni giorni dopo, i pazienti soggetti a questo genere di incidente, mostravano i primi sintomi di un avvelenamento da radiazione e, sulla parte esposta, si potevano notare delle bruciature da radiazioni che, in seguito all'avvelenamento, hanno causato la morte di tre pazienti. La commissione di inchiesta concluse che le cause principali erano imputate ad un programma scritto e sviluppato male, ma non specificatamente a molti errori di programmazione rilevati. La debolezza del programma venne individuata in una race condition. http://it.wikipedia.org/wiki/Therac-25 Digressione 1
  • 208. Digressione 1
  • 209. A software product of Multidata was involved in an accidental overexposure of patients in Panama in 2001 when the treatment planning software RTP/2 (vers. 2.11, 1991) reportedly contributed to 28 patients receiving excessive amounts of radiation at the Instituto Oncologico Nacional in Panama City.A panel of experts designated by the International Atomic Energy Agency delivered a comprehensive report in August 2001, finding that the software permitted incorrect forms of data entry which in turn had led to miscalculation of treatment times.[1] Multidata began a recall and in-field correction of its radiation treatment planning software in September 2001 with the issue of a software correction and detailed description of the cause and circumstances of the incorrect data entry. As in most radiotherapy departments, the one at ION uses a treatment planning system (TPS) to calculate the resulting dose distributions and determine treatment times. The data for each shielding block should be entered into the TPS separately. The TPS allows a maximum of four shielding blocks per field to be taken into account when calculating treatment times and dose distributions. Shielding blocks are used to protect healthy tissue of patients undergoing radiotherapy at the Institute, as is the normal practice. In order to satisfy the request of a radiation oncologist to include five blocks in the field, in August 2000 the method of digitizing shielding blocks was changed. It was found that it was possible to enter data into the TPS for multiple shielding blocks together as if they were a single block, thereby apparently overcoming the limitation of four blocks per field. As was found later, although the TPS accepted entry of the data for multiple shielding blocks as if they were a single block, at least one of the ways in which the data were entered the computer output indicated a treatment time substantially longer than it should have been. The result was that patients received a proportionately higher dose than that prescribed. The modified treatment protocol was used for 28 patients, who were treated between August 2000 and March 2001 for prostate cancer and cancer of the cervix. There were 17 deaths and 11 injuries.[2] The modified protocol was used without a verification test, i.e. a manual calculation of the treatment time for comparison with the computer calculated treatment time, or a simulation of treatment by irradiating a water phantom and measuring the dose delivered. In spite of the treatment times being about twice those required for correct treatment, the error went unnoticed. Some early symptoms of excessive exposure were noted in some of the irradiated patients. The seriousness, however, was not realized, with the consequence that the accidental exposure went unnoticed for a number of months. The continued emergence of these symptoms, however, eventually led to the accidental exposure being detected. This was in March 2001. In May 2001, the Government of Panama requested assistance under the terms of the Convention on Assistance in the Case of a Nuclear Accident or Radiological Emergency. In its response, the International Atomic Energy Agency sent a team of five medical doctors and two physicists to Panama to perform a dosimetric and medical assessment of the accidental exposure and a medical evaluation of the affected patients‟ prognosis and treatment. The team was complemented by a physicist from the Pan American Health Organization (PAHO), also at the request of the Government of Panama. The accidental exposures at the ION in Panama were very serious. Many patients have suffered severe radiation effects due to excessive dose. Both morbidity and mortality have increased significantly. This series of accidental exposures is unique. Previous radiation therapy accidental exposures that resulted in mortality had involved excessive doses of 30–50% more than prescribed. There are no reported previous accidental expoures in which the doses delivered were 50–100% above prescribed radiotherapy doses, with all affected patients being treated in the pelvic region. The IAEA report was consistent with the report made by local investigators. It was found that the radiotherapy equipment was properly calibrated and worked properly. The error was on the data entry, using a protocol not validated to enter more shielding blocks, that resulted in increased dose in the treatment. Most of the exposed patients have died, some radiation related, others by means of their advanced cancer. The Government of Panama agreed to share urgently the conclusions of the report to help prevent similar accidents. The physicists of ION involved were taken to trial by the patients families. http://en.wikipedia.org/wiki/Multidata_Systems_International Digressione 2
  • 210. Dalla teoria alla pratica… • Una volta messa a fuoco la proprietà/comportamento/funzione/livello di servizio è possibile capire se il sistema fallisce nell‟esibirli/erogarli/rispettarli. • E‟ cioè possibile capire se il sistema ha fatto un “errore” o è poco performante/usabile… • ..e dare un adeguato feedback al fornitore (o colui che deve garantire l‟affidabilità e continuità del servizio).
  • 211. Cos‟è un “baco”?
  • 212. Cos‟è un “baco”? 9/9/1947 Harvard Mark II 1545 Relay #70 Panel F (moth) in relay
  • 213. Cos‟è un “baco”? Tantissime opinioni e definizioni (non c‟è accordo e purtroppo si trovano un sacco di scemenze). Diffidate dei forum sul Web! Io farò riferimento sopattutto (ma non solo) allo standard IEEE 610.1 (Standard Glossary of Software Engineering). Parhami, B. (1988). From defects to failures: a view of dependable computing. ACM SIGARCH Computer Architecture News, 16(4), 157-168.
  • 214. Cos‟è un “baco”? Bug: la causa (“riconducibile” al codice di un programma) di un “failure” del programma stesso. Anche, la “anti-feature” per cui un programma esibisce un comportamento scorretto/inadeguato.
  • 215. Cos‟è un “baco”? Bug: la causa (“riconducibile” al codice di un programma) di un “failure” del programma stesso. Anche, la “anti-feature” per cui un programma esibisce un comportamento scorretto/inadeguato. Failure: risultato/output/comportamento scorretto/inatteso/non conforme alle specifiche Gli utenti dovrebbero parlare di “failure” (malfunzionamento/guasto) non di bug (che è già una diagnosi). Allo stesso modo si dovrebbe parlare di “Incident Report” o “Failure/Issue Report” (segnalazione di malfunzionamento o problema) non di “Bug Report” a meno che non siate tester professionisti. Debugging invece è un termine corretto per la correzione del codice che ha causato il problema o comunque per l‟eliminazione della proprietà non desiderata.
  • 216. Cos‟è un “baco”? Bug: la causa (“riconducibile” al codice di un programma) di un “failure” del programma stesso. Anche, la “anti-feature” per cui un programma esibisce un comportamento scorretto/inadeguato. Allora un “bug” è l’errore di un programmatore?
  • 217. Cos‟è un “errore”? Una survey recente ha trovato 17 definizioni di “errore” (1); un‟altra che gli operatori sanitari possono formulare almeno 24 modi possibili di vedere questo stesso fenomeno (2). (1) Runciman WB. Shared meanings: preferred terms and definitions for safety and quality concepts. Med J Aust 2006;184(10 Suppl):S41–S43 (2) Elder NC, Pallerla H, Regan S. What do family physicians consider an error? A comparison of definitions and physician perception. BMC Fam Pract 2006;7:73.
  • 218. Cos‟è un “errore”? Una survey recente ha trovato 17 definizioni di “errore” (1); un‟altra che gli operatori sanitari possono formulare almeno 24 modi possibili di vedere questo stesso fenomeno (2). * Runciman, William, et al. "Towards an International Classification for Patient Safety: key concepts and terms." International Journal for Quality in Health Care 21.1 (2009): 18-26. failure to carry out a planned action as intended or application of an incorrect plan fallimento nel portare a termine una azione precedentemente pianificata come previsto o l’applicazione di una pianificazione scorretta
  • 219. “Errore umano” (human failure) Errore Violazione Slip/commission (attenzionali) Lapse/omission (di memoria) nel fare (ma pianificazione giusta) nel pensare (ma azione giusta) Mistake (rule o knowledge-based) Abituali sabotaggio Contingenti Eccezionali Ricorrenti Situazionali James Reason, 1990 volontariinvolontari Cos‟è un “errore”? Reason, James. Human error. Cambridge university press, 1990.
  • 220. “Errore umano” (human failure) Errore Violazione Slip/commission (attenzionali) Lapse/omission (di memoria) nel fare (ma pianificazione giusta) nel pensare (ma azione giusta) Mistake (rule o knowledge-based) Abituali sabotaggio Contingenti Eccezionali Ricorrenti Situazionali James Reason, 1990? Cos‟è un “errore”? volontariinvolontari  Errori di indicazione ad una prestazione (cf. Dlg. 187/2000)  Errori di indicazione a quella prestazione  Errori di esecuzione in radiologia diagnostica e in Interventistica  Errori di refertazione  Errori di comunicazione
  • 221. “Errore umano” (human failure) Errore Violazione Slip/commission (attenzionali) Lapse/omission (di memoria) nel fare (ma pianificazione giusta) nel pensare (ma azione giusta) Mistake (rule o knowledge-based) Abituali sabotaggio Contingenti Eccezionali Ricorrenti Situazionali James Reason, 1990  Errori di indicazione ad una prestazione (cf. Dlg. 187/2000)  Errori di indicazione a quella prestazione  Errori di esecuzione in radiologia diagnostica e in Interventistica  Errori di refertazione  Errori di comunicazione ? Cos‟è un “errore”? volontariinvolontari
  • 222.  Errori di indicazione ad una prestazione (cf. Dlg. 187/2000)  Errori di indicazione a quella prestazione  Errori di esecuzione in radiologia diagnostica e in Interventistica  Errori di refertazione  Errori di comunicazione “Errore umano” (human failure) Errore Violazione Slip/commission (attenzionali) Lapse/omission (di memoria) nel fare (ma pianificazione giusta) nel pensare (ma azione giusta) Mistake (rule o knowledge-based) Abituali sabotaggio Contingenti Eccezionali Ricorrenti Situazionali James Reason, 1990? Cos‟è un “errore”? volontariinvolontari
  • 223.  Errori di indicazione ad una prestazione (cf. Dlg. 187/2000)  Errori di indicazione a quella prestazione  Errori di esecuzione in radiologia diagnostica e in Interventistica  Errori di refertazione  Errori di comunicazione “Errore umano” (human failure) Errore Violazione Slip/commission (attenzionali) Lapse/omission (di memoria) nel fare (ma pianificazione giusta) nel pensare (ma azione giusta) Mistake (rule o knowledge-based) Abituali sabotaggio Contingenti Eccezionali Ricorrenti Situazionali James Reason, 1990? Cos‟è un “errore”? volontariinvolontari
  • 224. La visione di Reason (90s): Gli incidenti (o eventi avversi, cioè danni effettivi o potenziali a pazienti / perdite) avvengono come risultato della interrelazione tra “atti pericolosi/rischiosi” (“errore attivo”) compiuti contestualmente (real-time unsafe acts ) da parte di operatori di prima linea (front-line operators) e condizioni latenti preesistenti (“errore latente”). Cos‟è un “errore”?
  • 225. La visione di Reason (90s): Gli incidenti (o eventi avversi, cioè danni effettivi o potenziali a pazienti / perdite) avvengono come risultato della interrelazione tra “atti pericolosi/rischiosi” (“errore attivo”) compiuti contestualmente (real-time unsafe acts ) da parte di operatori di prima linea (front-line operators) e condizioni latenti preesistenti (“errore latente”). Cos‟è un “errore”? Real time? Non necessariamente! Unsafe? Non necessariamente! (cf. race conditions) Acts? Non necessaramente!
  • 226. J. Reason, 1997-2001 Lo Swiss Cheese Model (SCM)
  • 227. J. Reason, 1997-2001 Lo Swiss Cheese Model (SCM) Non rischio! * * : che è una “probabilità” di un evento “modulata” dall’impatto/i dell’evento
  • 228. J. Reason, 1997-2001 Pericolo Proprietà o qualità intrinseca di una determinata circostanza, azione o entità (materiale, attrezzature di lavoro, metodi e pratiche di lavoro) Perdita o Danno Alcuni buchi sono dovuti a fallimenti attivi Altri buchi sono dovuti a condizioni latenti (o patogeni residenti) Gli strati rappresentano difese, barriere, dispositivi di sicurezza Lo Swiss Cheese Model (SCM)
  • 229. J. Reason, 1997-2001 Pericolo Proprietà o qualità intrinseca di una determinata circostanza, azione o entità (materiale, attrezzature di lavoro, metodi e pratiche di lavoro) Perdita o Danno Alcuni buchi sono dovuti a fallimenti attivi Altri buchi sono dovuti a condizioni latenti (o patogeni residenti) Gli strati rappresentano difese, barriere, dispositivi di sicurezza Lo Swiss Cheese Model (SCM) negligenza imprudenza
  • 230. L‟idea è “discolpare” il singolo, considerando che il suo ”errore (fallimento) attivo” (e quindi l‟evento avverso che ne consegue, anche se non necessariamente) occorre in un contesto che lo favorisce o comunque non lo previene (o intercetta), dove cioè ci sono “errori latenti” (resident pathologies). L‟errore (attivo) è quindi manifestazione emergente di un problema sistemico dell‟intero sistema socio-tecnico, anche se fattualmente commesso da un attore allo “sharp end” o “front line”, in presenza di determinate condizioni. (cf.Turner „78, Perrow ‟84, Rasmussen & Pedersen „84) Lo Swiss Cheese Model (SCM)
  • 231. L‟idea è “discolpare” il singolo, considerando che il suo ”errore (fallimento) attivo” (e quindi l‟evento avverso che ne consegue, anche se non necessariamente) occorre in un contesto che lo favorisce o comunque non lo previene (o intercetta), dove cioè ci sono “errori latenti” (resident pathologies). L‟errore (attivo) è quindi manifestazione emergente di un problema sistemico dell‟intero sistema socio-tecnico, anche se fattualmente commesso da un attore allo “sharp end” o “front line”, in presenza di determinate condizioni. (cf.Turner „78, Perrow ‟84, Rasmussen & Pedersen „84) “systems accidents have their primary origins in the fallible decisions made by designers at high-level (corporate or plant) managerial decisions makers” (Reason, 1990) Lo Swiss Cheese Model (SCM)
  • 232. Lo Swiss Cheese Model (SCM) L‟idea è “discolpare” il singolo, considerando che il suo ”errore (fallimento) attivo” (e quindi l‟evento avverso che ne consegue, anche se non necessariamente) occorre in un contesto che lo favorisce o comunque non lo previene (o intercetta), dove cioè ci sono “errori latenti” (resident pathologies). L‟errore (attivo) è quindi manifestazione emergente di un problema sistemico dell‟intero sistema socio-tecnico, anche se fattualmente commesso da un attore allo “sharp end” o “front line”, in presenza di determinate condizioni. (cf.Turner „78, Perrow ‟84, Rasmussen & Pedersen „84)complexity, tight-coupling, opacity (cf. C. Perrow, 1984)
  • 233. La metafora medica adottata da Reason (patogeni e barriere immunitarie) ha reso il suo modello molto apprezzato dalla comunità medica (Institute of Medicine –To Err is Human, 1999), sia come modello di causazione, strumento di comunicazione (didattica), strumento di analisi, strumento di prevenzione/progettazione. L‟SCM ha subito negli anni anche numerose critiche (Perneger 2005; Shorrock et al. 2005; Leveson 2004; Luxhoj & Kauffeld 2003; Dekker 2002; Shappell &Wiegmann 2000), relativamente alla sua ambiguità metaforica ed effettiva utilità (ad esempio: cosa sono I buchi? Si causano a vicenda, si “spostano”…) Paradossalmente Reason non concepì mai un modello a strati di formaggio, nè ovviamente diede tale nome al suo modello di “accident causation” (parlò piuttosto di modello del “cumulative (unsafe) act effect”, che invece si deve a Lee. Reason afferma anzi che l‟SCM dovrebbe essere usato come strumento didattico e di comunicazione, non altro. Ma quale SCM innanzitutto? Lo Swiss Cheese Model (SCM)
  • 234. Mark I, 1990 Lo Swiss Cheese Model (SCM)
  • 235. Lo Swiss Cheese Model (SCM) Mark II, 1995
  • 236. Lo Swiss Cheese Model (SCM) Mark III, 1997
  • 237. Approcci differenti Gli incidenti sono dovuti ad una combinazione di fallimenti (organizzativi, collaborativi e individuali). Gli incidenti sono dovuti ad una combinazione di variabilities (irregolarità/anomalie) nel sistema sociotecnico (dimensioni organizzativa, sociale, ambientale, psicologica, tecnica, …) rispetto alla “normale” variabilità della performance.
  • 238. Gli incidenti sono dovuti ad una combinazione di fallimenti (organizzativi, collaborativi e individuali). Gli incidenti sono dovuti ad una combinazione di variabilities (irregolarità/anomalie) nel sistema sociotecnico (dimensioni organizzativa, sociale, ambientale, psicologica, tecnica, …) rispetto alla “normale” variabilità della performance. Approcci differenti
  • 239. Gli incidenti sono dovuti ad una combinazione di fallimenti (organizzativi, collaborativi e individuali). Gli incidenti sono dovuti ad una combinazione di variabilities (irregolarità/anomalie) nel sistema sociotecnico (dimensioni organizzativa, sociale, ambientale, psicologica, tecnica, …) rispetto alla “normale” variabilità della performance. Focus sulla prevenzione degli errori, progettazione di barriere più efficaci, analisi degli incidenti e ricerca della “causa radice” (root cause – cf. Fishbone diagram) Approcci differenti
  • 240. Gli incidenti sono dovuti ad una combinazione di fallimenti (organizzativi, collaborativi e individuali). Gli incidenti sono dovuti ad una combinazione di variabilities (irregolarità/anomalie) nel sistema sociotecnico (dimensioni organizzativa, sociale, ambientale, psicologica, tecnica, …) rispetto alla “normale” variabilità della performance. Gli incidenti sono inevitabili: focus sulla identificazione precoce delle variazioni notevoli (variabilities), analisi di pattern che hanno portato ad incidenti per loro identificazione futura, diminuzione del coupling, aumento della “trasparenza”… Approcci differenti
  • 241. Gli incidenti sono dovuti ad una combinazione di fallimenti (organizzativi, collaborativi e individuali). Gli incidenti sono dovuti ad una combinazione di variabilities (irregolarità/anomalie) nel sistema sociotecnico (dimensioni organizzativa, sociale, ambientale, psicologica, tecnica, …) rispetto alla “normale” variabilità della performance. Analisi delle “interfacce” e Focus sulle conseguenze inattese di processi/strumenti perfettamente razionali e ordinati (e ordinanti) in ambienti di lavoro naturalmente caotici. Approcci differenti
  • 242. Dalle singole cause alle configurazioni critiche Approcci differenti
  • 243. La sicurezza di un sistema non è nell’affidabilità dei singoli componenti ma delle interazioni tra questi rispetto ad un compito da realizzare. Approccio sistemico e interazionale-emergente
  • 244. SHEL e SHELL
  • 245. SHEL e SHELL SHEL (Software, Hardware, Environment, Liveware), Edwards, 1988. Liveware (operatori Team Management) Hardware (Strumenti, Manuali, Attrezzature) Software (norme, procedure, Pratiche) Environment
  • 246. SHEL e SHELL SHEL (Software, Hardware, Environment, Liveware), Edwards, 1988. Liveware (operatori Team Management) Hardware (Strumenti, Manuali, Attrezzature) Software (norme, procedure, Pratiche) Environment Componenti umane e sociali, negli aspetti cognitivi, emotivi, relazionali, comunicativi
  • 247. SHEL e SHELL SHEL (Software, Hardware, Environment, Liveware), Edwards, 1988. Liveware (operatori Team Management) Hardware (Strumenti, Manuali, Attrezzature) Software (norme, procedure, Pratiche) Environment E’ semplicemente il componente più flessibile, per questo si fa carico di sbilanciamenti nel sistema rendendo però il sistema instabile e soggetto a breakdown.
  • 248. SHEL e SHELL SHEL (Software, Hardware, Environment, Liveware), Edwards, 1988. Liveware (operatori Team Management) Hardware (Strumenti, Manuali, Attrezzature) Software (norme, procedure, Pratiche) Environment
  • 249. SHEL e SHELL SHEL (Software, Hardware, Environment, Liveware), Edwards, 1988. Liveware (operatori Team Management) Hardware (Strumenti, Manuali, Attrezzature) Software (norme, procedure, Pratiche) Environment “…è un mismatch tra le interfacce piuttosto che fallimenti catastrofici di singoli componenti a caratterizzare i disastri” (Edwards)
  • 250. SHEL e SHELL SHELL, Hawkins, 1987: al centro l‟elemento umano che interagisce con le altre componenti, in base alle proprie competenze, capacità ed esperienze.
  • 251. Cosa cercare  Le interfacce SHELL, il loro “fit”, la loro friction.  Gli errori, ragionate sul tipo, quindi gli effetti e solo dopo le cosiddette “cause”.  Le irregolarità (variability).  i fattori nel contesto, nelle decisioni, nelle cose date per scontate, nelle omissioni, nelle interazioni SHELL.
  • 252. Mistake Defect /Fault Anomaly Failure Incident & Side Effects Error Metaphormism Metamorfismo degli errori Error
  • 253. Mistake Defect /Fault Anomaly Failure Incident & Side Effects Error Metaphormism Metamorfismo degli errori Error Component/ Logic Information System Unintended Consequences!
  • 254. Mistake Defect /Fault Anomaly Failure Incident & Side Effects Error Metaphormism Metamorfismo degli errori Qui gli ingegneri più “meccanici” considerano anche “malfunctioning” (subsystem) e “degradation” (service) Questo termine è quello più corretto in ambito di “test”, ma poco comune in “uso”… Questi termini sono “quasi” sinonimi. Defect è più “hardware”; Fault è più “software”, è un “errore” nel codice. Error
  • 255. Mistake Defect /Fault Anomaly Failure Incident & Side Effects Error Metaphormism Metamorfismo degli errori Error
  • 256. • :Bohr bug: /bohr buhg/ [from quantum physics] n. A repeatable {bug}; one that manifests reliably under a possibly unknown but well-defined set of conditions. Antonym of {heisenbug}; see also {mandelbug}, {schroedinbug}. • :heisenbug: /hi:'zen-buhg/ [from Heisenberg's Uncertainty Principle in quantum physics] n. A bug that disappears or alters its behavior when one attempts to probe or isolate it. Antonym of {Bohr bug}; see also {mandelbug}, {schroedinbug}. • :mandelbug: /mon'del-buhg/ [from the Mandelbrot set] n. A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a {Bohr bug}, rather than a {heisenbug}. See also {schroedinbug}. • :schroedinbug: [MIT: from the Schroedinger's Cat thought-experiment in quantum physics] n. A design or implementation bug in a program which doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years. BugTaxonomy
  • 257. Feedback
  • 258. Feedback
  • 259. Feedback In realtà la segnalazione può essere più specifica: • sw-bug (baco dovuto ad errore di programmazione) • doc-bug (errore nella documentazione, da correggere) • change-request / feature request (usability, performance, flavour,…) richiesta di modifica/aggiunta (usabilità, performance, estetica, …) (piccolo miglioramento/aggiunta, dentro l’offerta) • design-change-request / feature request richiesta di evoluzione (grande impatto, necessita analisi e nuova offerta)
  • 260. Feedback Si può aggiungere anche la priorità di segnalazione: • Blocker - Application or major section freezes, crashes, or fails to start. Data is corrupted. Critical Key feature does not work, cannot be used, or returns incorrect results. • Major - Key feature is difficult to use or looks terrible.A secondary feature does not work, cannot be used, or returns incorrect results • Normal- Secondary feature is difficult to use or looks terrible. Minor feature does not work, cannot be used, or returns incorrect results • Minor - Secondary feature has a cosmetic issue. Minor feature is difficult to use or looks bad. • Trivial - Minor glitches in images, not so obvious spell mistakes, etc • Enhancement - Improvement to product features due to bad usability or based on feedback from users.
  • 261. Feedback
  • 262. Feedback
  • 263. Feedback More at http://www.webresourcesdepot.com/9-free-and-open-source-bug-tracking-softwares/ Pretendete dal fornitore accesso a o installatevi un vostro issue/bug tracking system ! (ce ne sono di free e open-source…)
  • 264. Workflow Workflow è la specifica (più o meno formale) di un flusso di lavoro, cioè di come varie attività si articolano per produrre un risultato e raggiungere un obiettivo. Tale specifica può essere computazionale, cioè guidare l‟attività ordinante di un sistema informatico (essendo eseguibile dalla macchina sottostante).
  • 265. Workflow e Workaround Specifica (modello) di un fenomeno e fenomeni devianti da tale specifica sono “due facce della stessa moneta”… (non vi è l‟una senza l‟altra)
  • 266. Workflow e Workaround Prima dobbiamo studiare l‟uno (il workflow) per comprendere l‟altra (il “work” intorno al “flow”, workaround). Il workaround può essere visto come specifica incarnata (embodied) o “situated” di come il lavoro dovrebbe essere eseguito. Quindi anche come “requisito” in vivo.
  • 267. Use Cases – Casi d’Uso
  • 268. 0 5 10 15 20 25 30 35 40 1 2 3 4 5 6 Familiarità Concetto Caso d'Uso Use Cases – Casi d’Uso
  • 269. Il “caso d‟uso” è l‟oggetto di analisi che collega la specifica dei requisiti (cosa il sistema informatico fa e come, che obiettivi permette di raggiungere) con la specifica del workflow (come si comporta il sistema sociotecnico che integra il sistema) Use Cases – Casi d’Uso
  • 270. Un caso d‟uso specifica un obiettivo, e descrive le interazioni tra utenti e sistema per raggiungere tale obiettivo esprimendole come insieme specifico di percorsi (o scenari) possibili, che è rappresentabile anche graficamente attraverso una mappa di processo (o diagramma delle attività, modello di processo). Use Cases – Casi d’Uso
  • 271. “Caso” è il nome che Jacobson nel 1992 ha dato per descrivere processi, o meglio task (che hanno obiettivi!). Il suo obiettivo era «catturare» i comportamenti rilevanti e le interazioni significative, in maniera comprensibile non solo agli specialisti. Use Cases – Casi d’Uso
  • 272. A seconda di quanto è centrale il sistema informatico (l‟uso) o il sistema sociotecnico (vari attori aziendali che interagiscono) si suole chiamarli Use Cases o Business Cases. Per noi il nome è indifferente… vogliamo identificare un obiettivo e dire come utenti e sistema lo “raggiungono” passo dopo passo. Use Cases – Casi d’Uso
  • 273. • Business Use Cases (BUC) e System Use Cases (SUC), definiscono la stessa realtà a diversi livelli di descrizione, da diverse prospettive.Alistair Cockburn distingue tra: – Cloud level: • sintesi di alto livello, strategico – Kite level • il sistema organizzativo (socio-tecnico) in cui interagiscono gli attori per un certo scopo (comune e di alto livello) – Sea level • il sistema informativo/informatico con cui interagiscono gli attori per un certo obiettivo (usufruire di una certa funzionalità). – Le interazioni che sono possibili col sistema – Le funzionalità esposte (o da esporre, vedasi i requisiti funzionali) – Fish level • rappresenta i dettagli implementativi architetturali, moduli di sistema – Clamp level, • rappresenta i dettagli implementativi di singolo modulo Use Cases – Casi d’Uso
  • 274. La descrizione dei percorsi/scenari per raggiungere un obiettivo può essere: – Narrativa (per «scenari», «vignette», «user story», ...) – Strutturata (per «passi» e selezioni) – Una via di mezzo – Diagrammatica/iconica (modello di processo, diagramma delle attività,flochart. ...) Use Cases – Casi d’Uso
  • 275. Nota bene: uno scenario è un singolo modo di raggiungere l‟obiettivo; è un singolo percorso (un elenco ordinato di passi), cioè la descrizione dettagliata di una possibile sequenza di (inter)azioni verso l‟obiettivo. Use Cases – Casi d’Uso
  • 276. Un caso descrive cosa può succedere; uno scenario invece dice cosa succede se certe condizioni sussistono. Quindi un UC è un insieme di possibili scenari (legati insieme da un obiettivo). Si chiamano anche percorsi perché in una mappa di processo sono un percorso da «start» a «end». Use Cases – Casi d’Uso
  • 277. Dalla descrizione testuale (o dal diagramma) si evincono gli attori (o ruoli, o “personae” a seconda delle metodologie). – Sono persone, unità organizzative, altri sistemi, device. Ogni “attore” indica un ruolo che una entità può avere quando interagisce e comunica nel/con il sistema, Un attore può interagire in più casi, eventualmente con un ruolo diverso in ciascuno di essi. Se l‟attore non è umano, è comunque qualcosa il cui comportamento è autonomo. Use Cases – Casi d’Uso
  • 278. Un actor è particolarmente importante – primary: detiene l‟obiettivo principale, la motivazione scatenante – initiator: inizia il caso d‟uso, mosso da una intenzione compie la prima interazione. Gli altri attori “reagiscono” all‟iniziativa del primary/initiator (e.g., il receiver). Nei SUC il sistema è il semplice raggruppamento di funzioni, come le vedono e ne usufruiscono gli utenti. Use Cases – Casi d’Uso
  • 279. Le associazioni definiscono delle relazioni tra – Attori e Attori: generalizzazioni – Attori e UC: interazioni (partecipazioni in un UC) – UC e UC: generalizzazioni e dipendenze • Dipendenza “includes” – un caso include (e “usa”) un altro caso se nell‟esecuzione del primo è sempre compresa l‟esecuzione del secondo. Il caso incluso è un insieme di interazioni/comportamenti notevole compreso in quello più generale. • Dipendenza “extends” – Un caso estende un altro caso se indica qualcosa che si può fare sotto determinate condizioni (da specificare) e che particolareggia,“estende” un certo UC. L‟esteso si dice che “usi” (dipendenza “uses”) l‟estendente. Attori, casi e associazioni si possono rappresentare graficamente: diagrammi UC Use Cases – Casi d’Uso
  • 280. attore caso d’uso interazione dipendenza «includes» «uses» dipendenza «extends» Associazione di generalizzazione Use Cases – Casi d’Uso
  • 281. Use Cases – Casi d’Uso
  • 282. Accettazione Paziente Prescrizione Esame Prenotazione Esame Preparazione Esame Esecuzione Esame Refertazione Esame Recupero Referto (+img) Diagnosi e Decisione Medica Settaggio Macchina Acquisizione Immagine Analisi ed elaborazione Controllo Qualità Archiviazione Use Cases – Casi d’Uso
  • 283. Use Cases – Casi d’Uso
  • 284. Use Cases – Casi d’Uso Actors Physician: examine patients, obtain medical histories, diagnose illnesses, or prescribe and administer treatment for people suffering from injury or disease. Radiologist: is a physician who has specialized training in obtaining and interpreting medical images, which makes him or her an imaging expert. Radiographer: is a medical professional who creates medical images of the human anatomy to aid radiologists and other doctors diagnose and treat illness and injury. Modality: equipment or probes used to acquire images of the body (CR, MR, CT, US or NM). Scheduler: staff who schedule orders. Use Cases Create order: This use case allows you to create a radiology order indicating the type of procedure and priority, according to the patient examination. Schedule order: This use case allows you to schedule the date of the performance of radiologic procedures requested by the referring physician in the order. Furthermore, to assign the specialist in charge of diagnosing the requested study. Create study: This use case allows the acquisition of patient images in the modality. Create report: This use case allows you to create reports with a diagnosis of a patient, according to the results of imaging studies performed. View image: This use case allows you to view digital medical images of a patient, that can be manipulated by adjusting brightness and contrast, measurements, zooming, etc.
  • 285. Convenzioni per la loro scrittura: 1. I nomi: Per i casi: verbi (eventualmente con oggetto) o sostantivi predicativi (es.: „accettare paziente‟,„accettazione paziente‟). Per gli attori: termini singolari, che indicano ruoli, non posizioni. 2. Ogni attore deve interagire in almeno un caso. 3. Evitare di usare più di due livelli di descrizione. 4. Suggerire un ordine temporale tra casi solo per impilazione (non esplicitare il flusso!). 5. Usare poche (o nessuna) generalizzazioni tra gli attori. 6. Usare poco l‟<<extends>> e solo se il caso estende un altro in più scenari o è particolarmente rilevante. 7. Usare l‟<<includes>> solo se un caso include sempre l‟incluso, e questo è “abbastanza” articolato al suo interno. Use Cases – Casi d’Uso
  • 286. Quindi, ricapitolando, gli Use Cases rappresentano 1. un sistema in un contesto • cioè un raggruppamento di funzioni come le vedono gli utenti (il backend è meno importante). 2. gli attori • cioè i ruoli a cui interessa che il sistema esegua bene il suo compito o quelli che contribuiscono a che questo accada (una persona -l‟utente- o un altro sistema - una macchina). 3. le funzionalità / casi • sono le feature, i casi d’uso (cioè i tipi di uso), gli obiettivi degli attori, il fine che il sistema deve raggiungere per soddisfare le aspettative degli attori coinvolti. 4. le associazioni • relazioni tra attori, tra funzionalità diverse e tra attori e funzionalità (queste si chiamano interazioni o “comunicazioni”) 5. le dipendenze tra funzionalità e casi d‟uso diversi. 6. Tante altre cose, tra cui i passi necessari (previsti) per raggiungere un certo obiettivo (uno e uno solo!) Use Cases – Casi d’Uso
  • 287. La descrizione strutturata dell‟insieme dei percorsi (= insieme di passi) per raggiungere uno e un solo obiettivo, solitamente si imposta come segue: 1) Si scrive un «happy flow», o flusso di successo, o flusso base. Esso è una sequenza di passi (1..., 2..., 3...) che parte da uno stato iniziale (in cui valgono certe pre-condizioni) ad uno finale in cui l‟obiettivo del caso d‟uso è stato aggiunto (e valgono certe post-condizioni, o effetti del caso). 2) Per ogni passo si immagina come possono andare storte le cose, come si può deviare dal flusso base previsto; e si articola per ciascuno di questi sotto-casi una sottosequenza di azioni (1.1.1, 1.1.2, 1.1.3,.. 2.1.1, 2.2.1, 2.2.2, ...) che o raggiungono uno stato finale (in cui l‟obiettivo non è stato raggiunto), o si ricongiungono al flusso base «entrando» in uno dei suoi passi. Use Cases – Casi d’Uso
  • 288. Un caso d‟uso “reale” e vicino alla vostra esperienza… Studenti del master ASIDI classe 2008 Ada Bavarella Andrea Cecotti Federica Chelin MaiettiVaccari Diego Traverso (per il flusso interazioni) AndreaVezzali Claudio Mazzarino Giovanni Garbarino Michele Caliari Salvatore Petrenga Stefano Scavilla (per il diagramma) Use Cases – Casi d’Uso
  • 289. Diagramma dei casi d‟uso
  • 290. Flusso interazioni 1/7
  • 291. Flusso interazioni 2/7
  • 292. Flusso interazioni 3/7
  • 293. Flusso interazioni 4/7
  • 294. Flusso interazioni 5/7
  • 295. Flusso interazioni 6/7
  • 296. Flusso interazioni 7/7
  • 297. Rules, Policies, Conventions
  • 298. Use Cases => Business Processes
  • 299. Radiological Business Process
  • 300. Radiological Business Process Da: Wong, S.T. C.,Tjandra, D.,Wang, H., & Shen,W. (2003).Workflow-enabled distributed component-based information architecture for digital medical imaging enterprises. InformationTechnology in Biomedicine, IEEETransactions on,7(3), 171-183.
  • 301. Processo di Refertazione http://www.webcitation.org/6GgbqGqQ1
  • 302. Processo di Refertazione da Gibellini, 2012
  • 303. Siegel E, Reiner B.Work flow redesign: the key to success when using PACS.AJR Am J Roentgenol 2002; 178(3): 563–566. Prima della “cura” (informatizzazione)
  • 304. Siegel E, Reiner B.Work flow redesign: the key to success when using PACS.AJR Am J Roentgenol 2002; 178(3): 563–566. Dopo la “cura” (informatizzazione)
  • 305. Attività - Task Eventi Instradatore, Gateway Connettore, transizione Business Process Modeling Notation I simboli
  • 306. • Una attività (o task) è un qualche passo di un processo in cui viene svolto un lavoro (da uno o più persone/sistemi). • La potete vedere come uno stato in cui il sistema (socio-tecnico) “fa qualcosa”. • Quando un‟attività è stata completata si passa alla successiva attività, tramite una transizione. Business Process Modeling Notation Le attività
  • 307. Attività Atomica (per il livello di dettaglio della nostra modello): eseguita una volta sola in un processo. Attività Composta: al suo interno c‟è un sotto-processo (eventualmente esplicitato a parte)+ Attività che cicla: può essere eseguita più volte durante lo stesso processo. Business Process Modeling Notation Le attività
  • 308. • Un evento è semplicemente qualcosa che accade durante l'esecuzione di un processo (flusso di lavoro). • Gli eventi possono iniziare (e. iniziali), interrompere (e. intermedi) o far terminare un processo (e. finali). • Gli eventi influenzano il flusso delle attività in modo «asincrono». – Tipicamente fanno terminare attività e la loro attesa mette in pausa un processo. iniziali intermedi finali Business Process Modeling Notation Gli eventi
  • 309. *   3 Message: “E‟ arrivato un messaggio!”, “un dato è diventato disponibile!” Rule: Si è verificata una certa condizione, quindi… (secondo una regola ben precisa) Time: “E‟ ora!”, o “è passato quanto doveva passare!” Multiple: “Qualcosa di complesso si è appena verificato” Start: Inizia il processo! (senza troppi motivi) Si distinguono in base alle condizioni correlate. Rappresentano un evento del tipo: “è successo questo e quindi il processo inizia!”. Business Process Modeling Notation Gli eventi iniziali
  • 310. Message: “E‟ arrivato un messaggio!”, “un dato è divenuto disponibile!” Rule: Si è verificata una certa condizione, quindi… (secondo una regola ben precisa) Time: “E‟ ora!”,“è passato quanto doveva passare!” Multiple: “Qualcosa di complesso si è appena verificato”  3 33 Compensation: C‟è bisogno di annullare quanto fatto e ripristinare una situazione accettabile. Error: E‟ stato compiuto un errore. Operazione annullata *  Business Process Modeling Notation Gli eventi intermedi
  • 311. *Richiedere Cartella Clinica Arrivo Messaggio da altro ospedale Esegui Anamnesi Rappresentano ciò che può succedere durante la normale esecuzione di un processo, asincronamente (cioè «inaspettatamente»). Business Process Modeling Notation Gli eventi intermedi
  • 312. Attesa di miglioramento Aumentare antibiotici  dopo 24 ore Quando un evento intermedio è collocato sul bordo di una attività, significa che l‟attività stessa dovrebbe essere interrotta qualora l’evento accadesse. Business Process Modeling Notation Gli eventi intermedi
  • 313. Somministrazione Antibiotici Sospendere cura Questo tipo di eventi può essere usato per gestire le «eccezioni» e le cose impreviste (cioè di cui non si prevede nè se, nè quando accadono). Business Process Modeling Notation Gli eventi intermedi 33 Prescrizione ematocrito evento di completamento attività, implicito
  • 314.  Message: Alla fine del processo sarà disponibile un messaggio. Multiple: Alla fine del processo, si avranno molti effetti. 33 Compensation: Alla fine del processo si dovranno “aggiustare” un po‟ le cose. Error Il processo è terminato perché è stato compiuto un errore. * End: Termina il processo! (senza troppe spiegazioni) Indicano i risultati del particolare evento “il processo è terminato”. Business Process Modeling Notation Gli eventi finali
  • 315. • I gateway sono elementi che usiamo per instradare il flusso delle attività. – Solitamente sono posti al “bivio” tra due (o più) alternative. • Possono sia dividere che unire diverse strade di attività. • Si usano quando il flusso deve essere “controllato”, cioè quando – più cose possono essere fatte in parallelo – alcune strade sono alternative ad altre. Business Process Modeling Notation I Gateway
  • 316. • possono essere di 4 tipi: • Inclusivi • Esclusivi • Paralleli + basati su dati basati su eventi  • Complessi X questo può essere usato per unire due percorsi uguali da un certo punto in avanti Business Process Modeling Notation I Gateway
  • 317. rappresentano punti in cui il processo può prendere una sola di due o più strade alternative, in base: – ad una certa condizione (guard condition) vera sui dati presenti nel sistema. – all‟occorrenza di un certo evento.  Esame TC Donna Incinta? Proporre Alternativa Eseguire TC S N Proporre Alternativa X Eseguire Alternativa Annullare Esame *  * OK Business Process Modeling Notation I Gateway esclusivi
  • 318. rappresentano punti in cui il processo prende due o più strade eventualmente in parallelo. Esecuzione Esame Stampa Digitale Creazione scheda Scrittura Referto Inviare Referto+ + sincronizzazione Business Process Modeling Notation I Gateway inclusivi
  • 319. • I gateway inclusivi rappresentano punti in cui il processo può prendere una o più strade, eventualmente in parallelo. Richiesta Referto Eseguire Modo A Richiesto Modo A Rich. B Eseguire Modo C Eseguire Modo B Richiesto Modo C Inviare Referto Business Process Modeling Notation I Gateway inclusivi
  • 320. A questo punto possiamo vedere gli scenari come – una particolare sequenza di attività da uno stato iniziale ad uno stato finale. – un processo rappresenta più scenari, cioè più modi di arrivare al traguardo (un evento terminale) a partire dallo start! (evento iniziale) scenario 1 scenario 2 X X scenario 3 Business Process Modeling Notation
  • 321. Le istituzioni, le aziende, insomma i sistemi sociotecnici, sono rappresentati da «pools» (piscine). In ogni pool, le singole «corsie» (lanes) identificano ruoli aziendali ben precisi. Business Process Modeling Notation Enti & Ruoli / Pools & Lanes
  • 322. Tra ruoli possono passare «flussi» di attività (passaggi di consegna – linee continue) o «flussi di informazioni» (comunicazioni, linee punteggiate), oppure queste possono andare in lettura e scrittura su artefatti (documenti) condivisi. Business Process Modeling Notation Enti & Ruoli / Pools & Lanes
  • 323. Eventuali dipartimenti o sottounità all‟interno di una entità organizzativa (pool) possono essere rappresentati come aggregazione di lane, corsie. Business Process Modeling Notation Enti & Ruoli / Pools & Lanes
  • 324. Workflows • Di seguito riporto due modelli di processo radiologico fatti da esperti come voi nel Master ASIDI 2008. • Potete identificare (e comprendere) le differenze? • Potete migliorarli e quindi farne uno nuovo?
  • 325. Cecotti et al. 2008
  • 326. Caliari et al. 2008
  • 327. Workarounds
  • 328. Workarounds
  • 329. Workarounds • Un interesse crescente • Molte definizioni. • Qui un elenco piuttosto aggiornato (2013): http://goo.gl/BUKDJ
  • 330. Workarounds Kobayashi et al. 2005 CHI
  • 331. “any behavior end-users of a technology, or the members of an organization, intentionally exhibit, also on a regular basis, to reach a legitimate and agreed goal (such as completing a work item or task), in spite of either the technology or an organizational procedure” (Cabitza and Simone, 2013) Workarounds
  • 332. “qualsiasi azione relativa all'esecuzione di un processo o di un compito (supportati dal sistema informatico) che non è prevista o descritta nei manuali di uso del sistema informatico e/o nei manuali che descrivono tale processo o procedura. ” (Cabitza, 2013) Workarounds
  • 333. Non è una vera e propria “violazione” in quanto non è un “errore” volontario (cf. Reason), ma un comportamento che va comunque dritto allo “scopo” principale; Semplicemente… non è qualcosa condotto come specificato o previsto o concordato o descritto in un manuale. Workarounds
  • 334. Non è una vera e propria “violazione” in quanto non è un “errore” volontario (cf. Reason), ma un comportamento che va comunque dritto allo “scopo” principale; semplicemente, non è qualcosa condotto come specificato o previsto o concordato o descritto in un manuale. A volte sarebbe più giusto chiamarli “workthrough” o “usi creativi del sistema”… Workarounds
  • 335. Anche se tali workaround sono a volte più efficienti della procedura ufficiale (o più efficaci, o più agevoli, etc.) essi non sono del tutto esenti da rischi, o da conseguenze inattese anche gravi (eventi avversi.) Questo non perché siano azioni o usi buoni o cattivi in sè. Semplicemente perché non sono “visibili” e perché danno spesso per scontata (o assumono indefinitivamente) l‟immutabilità del sistema! (o di altre condizioni al contorno, più o meno visibili). Workarounds
  • 336. Tre esempi presi da… Workarounds Niazkhani, Z., Pirnejad, H., van der Sijs, H., & Aarts, J. (2011). Evaluating the medication process in the context of CPOE use: the significance of working around the system. International Journal of Medical Informatics, 80(7), 490-506.
  • 337. Workarounds
  • 338. Workarounds
  • 339. Workarounds Kobayashi, M., Fussell, S. R., Xiao, Y., & Seagull, F. J. (2005). Work coordination, workflow, and workarounds in a medical context. In CHI'05 extended abstracts on Human factors in computing systems (pp. 1561- 1564). ACM. Da:
  • 340. Due esempi presi da… Workarounds Azad, B., & King, N. (2011). Institutionalized computer workaround practices in a Mediterranean country: an examination of two organizations. European Journal of Information Systems, 21(4), 358-372.
  • 341. Distinguiamo tra SystemWorkaround: es.: bypasso/passo-sopra il sistema informatico, seguendo la procedura (ad es.: su cartaceo), oppure fuori dalla procedura. ProcessWorkaround: es.: bypasso la procedura (ma raggiungo l‟obiettivo primario) con o senza il supporto del sistema informatico. Workarounds
  • 342. Spesso siamo in presenza di entrambi soprattutto quando procedura organizzativa e sistema informatico sono fortemente correlati, cioè quando il secondo “enacta” (cioè realizza, implementa, supporta in maniera importante) il workflow che specifica computazionalmente la prima… Workarounds
  • 343. Spesso sono comportamenti o usi del sistema che rimangono “nascosti” (e non vengono pubblicizzati volentieri) o sono addirittura “inconsci”, cioè legati a convenzioni abituali non esplicite, o a particolari situazioni (ad es.: emergenze) quando “si sa” che il sistema e/o le procedure “ideali” non permetterebbero di erogare il servizio base (ad es.: la diagnosi, la terapia di un paziente) adeguatamente come necessario. Workarounds
  • 344. Per questo “estrarre” (elicitare) workarounds dagli utenti è difficile. Ci si può trovare di fronte: Workarounds  l‟atteggiamento ostruzionistico di chi sa di fare qualcosa che non dovrebbe (rispetto alla procedura ufficiale o alle indicazioni degli informatici). l‟atteggiamento sfidante di chi non vede l‟ora di dare visibilità alla propria contrarietà al sistema/procedura. una persona del tutto inconsapevole di attuare un certo workaround (perché ignora la procedura o il manuale del sistema informatico).
  • 345. Riuscite a ricordare casi di workaround che siano attuati nella vostra realtà “nonostante” (o all‟interno) del workflow “ufficiale” ? e quindi riflettere sulla loro genesi (quale ostacolo, quale “viscosità” di processo li ha causati), il loro metamorfismo, il loro valore, la loro utilità, in cosa consistono esattamente ? Workarounds
  • 346. Se lo potete fare, partecipate anche voi all‟iniziativa ospitata nel Wikispaces all‟URL http://usieprocessiinradiologia.wikispaces.com/ o http://conseguenzeinatteseinradiologia.wikispaces.com/ ! e riportate le vostre esperienze in qualsiasi modo (la forma non è importante, la testimonianza sì) o riportate l‟esperienza di vostri colleghi e conoscenti direttamente, od invitandoli al questionario all‟indirizzo: http://goo.gl/hxWbF. Workarounds
  • 347. Appunti personali _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________
  • 348. _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________
  • 349. _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________ _______________________________________