Introduzione agli Use Case

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Introduzione agli Use Case"

Transcript

1 Capitolo 3 Introduzione agli Use Case Introduzione Il problema di questo particolare progetto è che le specifiche continuano a variare! LVT Un software veramente forte è in grado di cambiare i propri utenti DONALT KNUTH Il presente capitolo è dedicato all illustrazione dei concetti forniti dallo UML per supportare il delicato processo di analisi dei requisiti utente; l attenzione sarà puntata sulla sua prima vista: la Use Cases View (Vista dei Casi d Uso). In questa fase della modellazione del sistema è importante cercare di astrarsi il più possibile dall implementazione dello stesso: bisogna concentrarsi su cosa il sistema dovrà fare e non sul come. Sebbene i casi d uso siano utilizzati quasi esclusivamente per catturare i requisiti del cliente, essi si prestano a documentare funzionalità offerte da qualsiasi entità: sistema, sottosistema o classe. I casi d uso sono modelli importantissimi nel contesto del ciclo di vita del software, sia perché sono quelli su cui il cliente appone la sua firma, sia perché stabiliscono in maniera inequivocabile o dovrebbero farlo quali funzioni il sistema dovrà fornire, le relative modalità di fruizione nonché il modo in cui trattare eventuali anomalie che potrebbero verificarsi. Costituiscono inoltre, già di per sé un prodotto di eccezionale importanza da consegnare al committente, in quanto, corredate da altri manufatti il modello ad oggetti del dominio per esempio, le viste dei casi d uso condensano l analisi del business dell organizzazione. La tecnologia evolve molto rapidamente, mentre in genere l evoluzione del business si consideri per esempio un sistema bancario è decisamente meno rapida. Pertanto i modelli dei casi d uso si prestano a essere usate per molteplici funzioni:

2 2 Capitolo 3. Introduzione agli Use Case implementazioni di nuove versioni del sistema, ottimizzazione dei processi interni, addestramento del personale, ecc. Come illustrato nel capitolo precedente, i processi di sviluppo prevedono diverse versioni di modelli dei casi d uso: business e requirements (detta anche di sistema). Procedendo nelle varie fasi del processo si assiste a una graduale transizione sia del linguaggio, sia del livello di astrazione. Per ciò che concerne il primo, si assiste a un progressivo passaggio dal linguaggio del cliente a quello tecnico. Per quanto riguarda il livello di astrazione, si passa da un livello elevato a uno sempre più dettagliato fino a incorporare suggerimenti derivanti dall architettura del sistema. I processi di sviluppo del software più popolari prevedono, tra l altro, l integrazione di approcci Use Case Driven. Ciò implica che la vista dei casi d uso divenga il punto di riferimento per tutto il ciclo di sviluppo del sistema: dalla progettazione in termini sia di disegno, sia di architettura hardware allo sviluppo, ai test. La criticità della vista viene parzialmente attenuata dall integrazione di altri approcci, quali, per esempio, Architecture Centric e Risk Driven. I modelli dei casi d uso risultano costituiti da due proiezioni: statica e dinamica. La prima viene completamente catturata attraverso i diagrammi dei casi d uso, mentre per la seconda sono disponibili diverse alternative che variano dal linguaggio naturale a opportuni diagrammi UML (sequence, activity, ecc.). La proiezione dinamica dovrebbe, illustrare sia le sequenze di attività da svolgere quanto tutto funziona correttamente (best scenario, scenario migliore), sia l elenco completo degli inconvenienti che potrebbero insorgere, correlato dai provvedimenti che il sistema deve attuare per la relativa gestione. Quindi i programmatori, durante la fase di codifica, dovrebbero implementare il modello di disegno tenendo sotto controllo i casi d uso relativi alla parte di sistema oggetto dello sviluppo. Da quanto detto, va da sé che errori o lacune nelle viste dei casi d uso determinano problemi in tutte le restanti viste, fino a giungere, in situazioni estreme, all invalidazione della qualità del sistema finale: magari il sistema è tecnicamente ben congegnato, realizzato rispettando tutti i canoni della produzione del software ma, semplicemente, non risolve i problemi del cliente. Non bisogna sempre pensare all utente come l asino di turno che inserisce i dati quando il cursore lampeggia in una casella. Al fine di minimizzare i rischi dovuti a possibili analisi dei requisiti approssimative o errate, si preferisce incorporare nel processo di sviluppo approcci di tipo incrementale e iterativo, tipicamente guidati dall attenuazione dei fattori di rischio. Ciò permette di sottoporre al vaglio del cliente successive versioni del sistema per verificarne la rispondenza alle reali necessità ed eventualmente correggere tempestivamente la rotta. Lo stesso utente, potendo interagire con il sistema, o con una sua versione, riesce a chiarirsi le idee e a capire quanto i requisiti analizzati siano effettivamente rispondenti alle reali necessità: non a caso spesso si ricorre alla realizzazione di opportuni prototipi.

3 UML e ingegneria del software: dalla teoria alla pratica 3 La vista dei casi d uso viene illustrata partendo dalla visione globale; ne viene illustrata la suddivisione in proiezione statica e dinamica, per poi scendere via via nei particolari, con un approccio tipicamente top down. In questa trattazione si è deciso di non attribuire eccessiva attenzione al flusso delle azioni (descrizione del comportamento dinamico degli use case) così come definito dai Tres Amigos in quanto, nella pratica, non è infrequente il ricorso a tecniche sensibilmente divergenti da quelle standard in grado di apportare ambìti benefici. Tali tecniche sono oggetto del capitolo successivo. Prima di entrare nel merito dell oggetto di studio del capitolo, si è ritenuto opportuno presentare una breve digressione su cosa si intenda con la famosa spesso misteriosa definizione di requisiti utente e in cosa consista il relativo processo di analisi: tutti i tecnici ne hanno una percezione più o meno intuitiva, ma spesso ciò che è chiaro a livello intuitivo non è in definitiva facile da rendere a livello pratico. Nel corso del capitolo si utilizzano i termini use case e la relativa traduzione in lingua italiana casi d uso con significato assolutamente equivalente. I requisiti utente La realizzazione di un qualsiasi manufatto, e quindi anche di un nuovo sistema software, dovrebbe cominciare dalla raccolta dei relativi requisiti, la quale innesca il processo denominato ciclo di vita del software. Tipicamente la primissima fase è denominata analisi del business, in cui le informazioni raccolte e opportunamente elaborate (modello del business) costituiscono i prodotti di input della fase di analisi dei requisiti vera e propria. Visto lo stretto legame esistente tra le due fasi e le sovrapposizioni, non sempre è possibile effettuare una netta ripartizione tra le due. L iter inizia tipicamente con il team degli esperti analisti, corredato da qualche commerciale, che si reca presso il cliente. A dire il vero, nelle organizzazioni più complesse il compito è interamente demandato ad appositi team composti quasi esclusivamente dai famosi Business Analyst: persone esperte dell attività economica del cliente. Obiettivi della prima spedizione sono essenzialmente due: 1. capire (o carpire) le esigenze che determinano la necessità di un nuovo sistema informatico o dell aggiornamento di quello esistente; 2. analizzare lo scenario del cliente con particolare attenzione alle risorse disponibili: umane, tecnologiche (parco macchine, connessioni, reti, software utilizzati ) e, perché no, anche di budget. È consigliabile iniziare con una serie di interviste ai manager, sia perché essi sono in grado di fornire una buona visione di insieme dell organizzazione e della relativa attività economica, sia per evitare di urtarne da subito la suscettibilità.

4 4 Capitolo 3. Introduzione agli Use Case Gli analisti più esperti fanno precedere a ogni intervista l invio di un documento riportante i quesiti e gli argomenti di cui si intende discutere: proprio come taluni giornalisti politici italiani (trascurabili pretese dei cosiddetti politici). In questo contesto, tuttavia, si tratta di un buon espediente sempre che i manager leggano il questionario. Terminata la tornata iniziale, si redige un primo documento, corredato da un glossario, con la spiegazione degli acronimi e dei termini tecnici utilizzati (vocabolario del dominio del problema). Il passo successivo, purtroppo spesso trascurato, consiste nello scendere via via di livello nell organigramma dell organizzazione del cliente, fino a intervistare coloro che dovranno interagire direttamente con il sistema: i poveri utenti finali. Tipicamente, questi mancano di una visione d insieme, ma in compenso conoscono ogni dettaglio sul modo in cui le procedure vengono realmente eseguite: dalla teoria alla pratica. Durante le interviste può sorgere qualche problema: alcuni dipendenti, sentendosi minacciati dall introduzione di un nuovo sistema e magari indagati in qualche modo sulle relative mansioni, tendono a divenire improvvisamente reticenti ed enigmatici. Terminata anche questa fase, si redige una seconda versione del documento e qui cominciano le dolenti note. Il problema che può emergere a questo punto è che le versioni fornite dai manager potrebbero risultare discordanti o addirittura contraddittorie rispetto a quelle fornite da coloro che eseguono fisicamente le varie procedure. A chi credere? Si tratta di affrontare l eterno dilemma tra teoria e pratica. Cosa fare? Si reiterano le interviste, cercando di dettagliare maggiormente i punti controversi nel tentativo di rendere il tutto coerente, si riscrivono i vari documenti, ecc. Nei casi più estremi è necessario giungere a confronti all americana si mettono i manager faccia a faccia con i subalterni nei quali, stranamente, le versioni dei manager tendono a prevalere. Si riorganizza di nuovo quello che ormai è diventato un enorme ammasso di appunti e si redige un ennesimo documento che man mano ha acquistato anch esso di corposità. In questo documento sono condensati i famosi requisiti utente: le richieste legittime del cliente, le sue elucubrazioni mentali in termini tecnici si possono trovare sinonimi più incisivi le distorsioni, le aspettative, tanti omissis Quando ci sono da esprimere pareri o suggerimenti, nessuno riesce a fare a meno di fornire la propria visione: ognuno vorrebbe dimensionare il nuovo sistema a propria immagine e somiglianza. Quando poi giunge il fatidico momento di firmare il documento delle specifiche, si assiste al gioco del fuggi fuggi meglio noto come secondo sport nazionale: lo scaricabarile. Infine, ottenuta la validazione dal cliente, non è infrequente un attività di rielaborazione: si comincia a lavorare sul serio.

5 UML e ingegneria del software: dalla teoria alla pratica 5 Il primo embrione di analisi dei requisiti è tuttavia di grande interesse per i commerciali, in quanto dà un idea del giro d affari che ruota intorno al progetto: fa capire quanto ci si possa guadagnare Obiettivi dell analisi dei requisiti utente Durante la conduzione del processo di analisi dei requisiti utente risulta importante tenere bene a mente quali siano gli obiettivi che si vuole raggiungere, ossia: decidere e descrivere le specifiche, funzionali e non, concordate con il cliente le quali confluiscono nel contratto che l azienda sviluppatrice sottoscrive con il cliente; fornire una descrizione chiara e consistente delle funzionalità che il sistema dovrà realizzare: prodotto guida delle altri fasi del ciclo di vita del software; generare un modello che consenta di eseguire il test del sistema; iniziare a progettare l interfaccia utente del sistema; disporre, attraverso le varie versioni degli use case, di una traccia dell evoluzione del sistema e/o dei requisiti utente (i quali, tipicamente, si automodificano a ogni ciclo lunare); eseguire la stima dei tempi e quindi dei costi; pianificare il processo di sviluppo del sistema (attribuzione delle priorità, definizione delle iterazioni, ecc.). Per poter realizzare la vista dei casi d uso, è necessario definire precisamente il sistema (in termine dei suoi confini ), identificare correttamente gli attori, definire le funzioni dei vari diagrammi, determinare le relazioni tra use case e validare il sistema stesso. Si tratta di un attività che richiede un elevata interazione con il cliente e con le persone che rappresentano gli attori del sistema stesso. Sebbene ogni qualvolta venga proposto uno strumento dedicato all analisi concettuale di un sistema si affermi che esso possa essere facilmente compreso da clienti con nessuna esperienza informatica (vedi diagrammi E-R e/o DFD), nella realtà ciò si verifica molto raramente: almeno è questa la personale esperienza dell autore. Pertanto l analisi dei requisiti deve essere comunque espres-

6 6 Capitolo 3. Introduzione agli Use Case sa anche per mezzo di strumenti non eccessivamente formali, quali per esempio opportuni template o addirittura il buon classico documento in linguaggio naturale. Inoltre è sempre consigliabile pianificare opportune sessioni di training relative al formalismo utilizzato (per esempio use case), allo scopo di fornire agli utenti/clienti i requisiti necessari per leggere e interpretare i vari modelli che dovranno validare. Può succedere ogni riferimento alla vita reale dell autore è puramente casuale di sviluppare elegantissimi diagrammi dei casi d uso ben strutturati, colmi di relazioni e di generalizzazioni, giungere al momento di revisionarli con il team del cliente, e di vedere poi comparire progressivamente nei loro volti un certo sconforto di fronte al livello di astrazione prodotto. È bene ricordare che, seppure anche la vista dei casi d uso debba essere un modello Object Oriented a tutti gli effetti, è talvolta ahimè necessario sacrificare parzialmente la propria formalità al fine di favorire il dialogo con il cliente. Da tener presente che lo UML (secondo quanto riportato nei libri dei Tres Amigos) prevede di descrivere il comportamento dinamico dei casi d uso per mezzo del relativo flusso di eventi, il quale specifica quando uno use case inizia, quando termina, quando interagisce con un attore, quali oggetti vengono scambiati, ecc. Il ruolo dei vari diagrammi dei casi d uso, per tutta una serie di motivazioni, dovrebbe, in qualche modo, venir dimensionato a rappresentarne una sorta di overview. La speranza è che l utilizzo di un formalismo grafico renda il tutto più accattivante, immediato e comprensibile al cliente. Chiaramente, attraverso una serie di grafici non è possibile una completa descrizione di tutti i requisiti del cliente. Il monito da tenere sempre a mente è che una deficienza grave nell analisi dei requisiti può generare grandi problemi nel processo di sviluppo del software. Ciò però non deve neanche generare la paralisi del processo di sviluppo dovuta al timore di proseguire nelle fasi successive mentre i requisiti non sono ancora completi: in ultima analisi si utilizzano processi iterativi e incrementali anche per mitigare questi rischi. In ogni modo, la rappresentazione grafica è decisamente utile e molto accattivante, ma assolutamente non sufficiente.

7 UML e ingegneria del software: dalla teoria alla pratica 7 Un ultimo solo in senso temporale di esposizione aspetto da tenere bene a mente è che i requisiti utente variano: bisogna rassegnarsi all idea che, per quanto meticolosi, esperti e scaltri si possa essere, è impossibile prevedere tutti i dettagli fin dall inizio. Sebbene ciò possa apparire in contrasto con gli insegnamenti ricevuti nei banchi dell università, la realtà è che l evoluzione è insita nel destino dell universo e che i sistemi informatici non esulano da tale regola. Il sogno di alcuni manager informatici consiste nel congelare le specifiche prima di proseguire nell attività di codifica. Sebbene ciò possa sembrare logico, si corre l insignificante rischio di realizzare un sistema, magari bellissimo, che però semplicemente non era quello desiderato dal cliente e che non è di alcun aiuto: con un esempio, l utente ha bisogno di una scaletta per arrampicarsi sull albero e gli viene fornito un ascensore adatto a un grattacielo. Dunque, invece di investire un tempo eccessivo nell analisi dei requisiti nel vano tentativo di studiare ogni dettaglio per realizzare un modello perfetto prima di procedere alla fase successiva, paralizzando tra l altro l intero processo, forse potrebbe essere opportuno cercare sì di fare del proprio meglio, ma comunque avanzare con un processo di sviluppo di tipo iterativo e incrementale. Ovviamente ciò non significa realizzare un prodotto di scarsa qualità tanto dovrà cambiare. È necessario anticipare il problema progettando sistemi flessibili, cercando di circoscrivere le aree più a rischio di variazione, studiando opportuni piani per la gestione dei temutissimi change requirements. Indipendentemente dalla fase del ciclo di vita in cui ci si trova, il sistema varierà e il desiderio di cambiare persisterà per tutto il ciclo di vita E.H. BERSOFF Diagramma di diritti e doveri del cliente Uno dei problemi storici nel mondo della progettazione dei sistemi informatici risiede nel difficile rapporto, in genere di carattere comunicativo, che spesso si instaura tra tecnici informatici e committenti che necessitano di sistemi informatici per migliorare la qualità e l efficienza del proprio lavoro. Si tratta di problematiche antiche che rivivono sotto forme moderne. Materia certamente nota: la conoscono tutti fin dai primi corsi di programmazione, eppure si continua a perseverare nell errore in modo decisamente diabolico (con accezione latina). Obiettivo del presente paragrafo, giocando un po con i diagrammi dello UML, è di illustrare quelli che dovrebbero essere diritti e doveri delle due parti in causa: team tecnici e utenti/clienti. Si è deciso di presentare l argomento utilizzando un espe-

8 8 Capitolo 3. Introduzione agli Use Case diente tecnico: interfacce e componenti nel tentativo di rendere più piacevole la trattazione. (Ci si augura che ciò non disturbi l eterno sonno dell eccelso Cesare Beccaria A dire il vero ci sarebbero altri motivi ben più reali del presente paragrafo per turbare il riposo del sommo pensatore). Un interfaccia (in termini di classi) è a tutti gli effetti un contratto tra classi client che utilizzano i servizi e la classe server che li fornisce. Nel contesto della presente trattazione, entrambi i componenti (team tecnico e cliente) espongono una propria interfaccia (si impegnano a erogare determinati servizi: quelli appunto definiti nella propria interfaccia) e utilizzano i servizi esposti dall interfaccia dell altro componente. Quindi entrambi presentano sia comportamento da client (utilizzano determinati servizi), sia da server (implementano i servizi dichiarati dalla propria interfaccia). Il componente Cliente, poiché è quello che alloca le risorse economiche, può pretendere di accettare la sottoscrizione da un componente che esponga l interfaccia desiderata (offre precisi servizi). Quanto riportato nei prossimi paragrafi è una rivisitazione tecnica di vari libri e articoli. Il contributo maggiore comunque è dovuto, strano ma vero, alla rivista Microsoft Press e in particolare al Software Requirements di Karl Wiegers. Con riferimento alla fig. 3.1, di seguito viene presentata una disamina commentata dei vari metodi esposti nelle interfacce. La descrizione dei servizi esposti spesso si presta ad Figura 3.1 Diagramma dei componenti di diritti e doveri dei clienti. DoveriCliente Cliente +clarifyrequirements( requirements ) +maketimelydecision( requirements ) +maketimelydecision( solutions ) +respecttimeandcosts() +setrequirementspriorities( requirements ) +reviewmodel() +reviewprototype() +notifychangerequirements() +respectswdevelopmentsprocess() TeamTecnico DoveriTeamTecnico +setcontextlanguage( businesslanguage ) +setbusinessrules( businessrules ) +setobjectives( objectives ) +getrequirementsmodel() +getrequirementsmodelexplanation() +getsolutionideas( requirements ) +getsolutionideas( newproblem ) +setclientrespect() +setproducteasytouse( characteristics ) +changerequirements( newrequirements ) +getchangereqrealestimation() +getqualitysystem()

9 UML e ingegneria del software: dalla teoria alla pratica 9 essere illustrata per mezzo della tecnica denominata design by contract (trattato in maggior dettaglio nel capitolo dedicato ai principi base dell Object Oriented), e in particolare attraverso: 1. prerequisiti: quando un client generico utilizza un determinato servizio esposto da un server deve impegnarsi a rispettarne le relative eventuali precondizioni; 2. requisiti durante l utilizzo: responsabilità dei server che espongono servizi è garantire il soddisfacimento di determinate condizioni durante la fruizione del servizio stesso; 3. post condizioni: sempre i server, per ogni servizio esposto, devono assicurare, al termine dell erogazione dello stesso, il conseguimento dei risultati decretati nelle post condizioni, a patto chiaramente che i prerequisiti siano soddisfatti. setcontextlanguage(businesslanguage : Language) Questo metodo indica che il componente TeamTecnico dovrebbe fornire un servizio che permetta di sincronizzare il proprio linguaggio con quello utilizzato dal cliente, in altre parole è diritto di questi ultimi attendersi che il team degli analisti parli il linguaggio tecnico utilizzato nel proprio ambiente di business. Ciò però comporta il dovere dei clienti di provvedere le risorse necessarie (in termini di personale, di strutture, di documentazione nonché di tempo) affinché il team tecnico possa raggiungere l obiettivo di appropriarsi del linguaggio. Utilizzando il design by contract si può asserire: 1. i prerequisiti sono: il Cliente deve impegnarsi ad allocare le risorse necessarie per insegnare e verificare l esatto apprendimento del linguaggio tecnico del business; 2. i requisiti durante l utilizzo sono: il TeamTecnico garantisce di compiere ogni sforzo necessario per acquisire il linguaggio tecnico; 3. post condizioni sono: il team tecnico padroneggerà il linguaggio tecnico dell area business nei limiti imposti dalle relative necessità e dal tempo a disposizione. setbusinessrules(businessrules : businessrule[]) setobjectives(objectives : objective[])

10 10 Capitolo 3. Introduzione agli Use Case In modo completamente analogo al caso precedente, è del tutto legittimo attendersi che il cliente pretenda che il team tecnico acquisisca le regole vigenti nel proprio business e, in qualche modo, ne condivida gli obiettivi finanziari e strategici: i sistemi informatici, essendo parte importante di quelli informativi, recitano un ruolo di primaria importanza nel conseguimento degli obiettivi strategici delle aziende. Basti pensare ad esempio a siti e-commerce o a sistemi per la gestione degli investimenti bancari (area treasury). RequirementsModel : getrequirementsmodel() ModelExplanation : getrequirementsmodelexplanation() Altro diritto/dovere del cliente è richiedere di visionare il modello dei requisiti e di ricevere tutte le spiegazioni del caso. Per quanto riguarda il primo metodo (getrequirementsmodel), le precondizioni che deve rispettare il cliente sono di aver provveduto a invocare i metodi precedenti, ossia aver facilitato l apprendimento del proprio linguaggio, aver illustrato in maniera precisa e puntuale le business rules, aver spiegato i propri obiettivi ecc., mentre le condizioni durante l uso, garantite dal TeamTecnico, sono che il modello verrà prodotto in accordo alle informazioni fornite dal cliente e la post condizione è che il modello fornito sarà completo, rispondente alle esigenze del cliente e di elevata qualità tecnica. Per ciò che riguarda il secondo metodo (getrequirementsmodelexplanation), le precondizioni sono che il cliente abbia eseguito il metodo precedente, ossia abbia ottenuto una istanza del RequirementsModel. Le condizioni durante l utilizzo e le post condizioni sono piuttosto evidenti: il TeamTecnico deve adoperarsi per chiarire i dubbi espressi dal cliente e verificare se questi celino qualche requisito non detto e quindi fornire una spiegazione puntuale, precisa ed esauriente. setclientrespect() Questo metodo, in prima istanza, potrebbe sembrare piuttosto banale, e invece è proprio il caso di commentarlo. Spesso i team tecnici sembrano non nutrire il dovuto rispetto per il cliente (in questo contesto si fa riferimento all utente finale). Troppo spesso si considerano i clienti come gli zucconi di turno agli ordini del cursore lampeggiante, i quali, per definizione, non riescono mai a impostare i dati in maniera corretta. Suggeriscono nulla uno dei primissimi assiomi della programmazione: il cliente è uno sciocco o i famosi test dell asino da farsi per verificare se il sistema sia o meno a prova di utente? Talune volte sarebbe opportuno provare compassione (anche qui, accezione latina ovviamente) per la frustrazione spesso provata dai clienti che interagiscono con nuovi

11 UML e ingegneria del software: dalla teoria alla pratica 11 sistemi. Qualora tale frustrazione esista veramente, sarebbe il caso si interrogarsi se si è fatto del tutto per neutralizzarla o quantomeno minimizzarla. Naturalmente, se gli utenti/clienti forniscono indicazioni (requisiti) errati, difficilmente verificabili, c è poco da fare (vige l acronimo GIGO, Garbage In, Garbage Out ovvero entra spazzatura, esce spazzatura ; a questo acronimo viene spesso preferita la più prosaica versione SISO la cui traduzione viene demandata alla fantasia del lettore ), ma se i tecnici si ingannano con un idea preconcetta basata sulla propria, sopravvalutata esperienza e trascurano l attività di convalida con gli stessi utenti, allora difficilmente il sistema risulterà soddisfare le reali necessità degli stessi. Per entrare nel giusto spirito si provi a immaginare di dover realizzare un sistema complesso utilizzando un framework esistente, magari fornito da terze parti, non intuitivo e con scarsa documentazione tecnica: a chi non è capitato? getsolutionideas(newproblem : Problem) getsolutionideas(requirement : Requirement) Questi metodi decretano che il team di sviluppo deve essere in grado di comprendere le reali necessità del cliente eventualmente anche non dette o non pensate dal cliente ma comprese attraverso la sfera di cristallo chiamata esperienza e provvedere idee e alternative relative sia ai requisiti specificati dal clienti, sia a dubbi e perplessità palesate. In altre parole è diritto del cliente ottenere proposte di soluzioni relative ai propri problemi e requisiti basate su esperienza e competenza del team tecnico. Qualora la famosa esperienza manchi, non è comunque la fine del mondo: è possibile sopperire con una buona dose di impegno e intelligenza; ma se mancano anche queste qualità la situazione diviene davvero complicata. setproducteasytouse(characteristics : Characteristic[]) Visto e considerato che il cliente finanzia il sistema e sarà lui a utilizzarlo, dovrebbe essere del tutto comprensibile che si attenda di ricevere un prodotto il quale, ovviamente, assolva alle problematiche che ne hanno generato la necessità e che, al tempo stesso, sia semplice da utilizzarsi in funzione dei propri parametri/necessità. Talune volte i team tecnici costruiscono interfacce utente incomprensibili e disordinate o magari semplicemente ottimizzate in funzione della struttura del sistema o in base a quelle che erano considerate le esigenze dell utente dal team tecnico. Si tende banalmente a dimenticare chi sarà il fruitore ultimo del sistema stesso. Non è infrequente anche imbattersi in situazioni in cui l utente, per eseguire determinate funzionalità ricorrenti, sia costretto a eseguire tortuosi giri e incomprensibili procedu-

12 12 Capitolo 3. Introduzione agli Use Case re, mentre sarebbe del tutto legittimo attendersi un utilizzo più lineare, eventualmente ottimizzato in base ai servizi richiesti più frequentemente. Nei casi peggiori, sempre molto frequenti, le complicatissime interfacce utente sono solo la punta dell iceberg Accade che l intero modello del sistema sia basato su intuizioni tecniche, magari anche interessanti, ma lontanissime dalla realtà Nella fase di consegna si assiste alle crisi isteriche dell intuitore : Ma come? Non si riesce a forzare la realtà alla struttura del sistema?. ChangeRequirements(newRequirements : Requirements[]) Questo è indubbiamente il metodo che incute più paura di tutti: basta il nome per generare tremori nel team tecnico. Sfortunatamente si tratta di una pretesa legittima del cliente: l obiettivo comune delle parti dovrebbe essere quello di progettare un sistema di qualità che effettivamente soddisfi il cliente e non di consegnare qualcosa di eseguibile. In altri ambienti, per esempio nella costruzioni di edifici, risultano accettabili incursioni nel cantiere dei committenti con eventuali richieste di modifiche. Pertanto non c è da stupirsi che, iniziando a vedere il sistema reale e cominciando a interagirvi il cliente possa chiederne dei cambiamenti, perché per esempio non era riuscito a capire in anticipo eventuali problematiche o semplicemente perché erano state fraintese. Come al solito è necessario un mea culpa: quando l utente invoca il fastidiosissimo metodo changerequirements, quanta colpa ha veramente il cliente? Spesso accade anche che il team tecnico, pur avvertendo difficoltà o incongruenze, semplicemente le ignori dimenticando che prima o poi il problema si ripresenterà, ma questa volta amplificato dal fattore tempo. Continuando con l esempio dell edificio, è un po come se la squadra che lo sta costruendo si rende conto che gli spazi lasciati per le tubature sono assolutamente insufficienti, ma prosegue ugualmente nella costruzione, dimenticando che prima o poi bisognerà demolire il tutto e ricostruire e questa volta con pochissimo tempo a disposizione. L importante è fornire l edificio per la data di presentazione prevista, e poi Poi è sempre possibile inserire delle toppe. Estimation : getchangereqrealestimation(newreq : Requirement) Questo metodo è strettamente collegato a quello precedente. In caso di richiesta di cambiamenti dei requisiti, sarebbe naturale da parte del cliente ottenere una stima attendibile e onesta dei tempi necessari per soddisfare tali richieste. Nella realtà accade che le richieste ritenute più divertenti e meno ostiche tendano a ricevere una stima ottimistica, mentre altre, magari anche molto importanti, tendano a venir sovrastimate. A onor del vero va detto che, indubbiamente, uno dei principali moti-

13 UML e ingegneria del software: dalla teoria alla pratica 13 vi di sollecitudine dei team tecnici consiste nel giocare con nuovi giocattoli. Qualora venga fiutata la possibilità di poter cogliere l occasione per utilizzare nuove tecnologie, le stime tendono improvvisamente a divenire molto ottimistiche, mentre il caso contrario implica stime funeste. System : getqualitysystem(). Il commento di questo metodo viene deliberatamente lasciato al lettore. Esaurita l analisi dei diritti del cliente, si passa ora a esaminarne i doveri Alcuni di essi sono già stati espressi per mezzo di precondizioni dei metodi del TeamTecnico. In particolare è dovere del cliente insegnare il linguaggio tecnico, le regole dell ambiente oggetto di analisi, cercare di spiegarsi nel modo più chiaro possibile, ecc. A tal fine il cliente deve allocare tutte le risorse necessarie, tra cui il tempo, per illustrare, spiegare, verificare e così via. Clarification[] : clarifyrequirement(requirements : Requirement[]) Responsabilità dei clienti è fornire i requisiti al TeamTecnico, allocando il tempo necessario per chiarire quelli ritenuti meno evidenti. È importante che sia i requisiti, sia le relative spiegazioni siano precise e concise. Decision[] : maketimelydecision(requirements : Requirement[]) Decision[] : maketimelydecision(solutions : Solution[]) Altra responsabilità dei cliente consiste nel prendere decisioni e nel farlo in tempi umani e non geologici. In generale le decisioni del cliente dovrebbero essere relative sia alla selezione delle ipotesi di soluzioni ritenute più valide tra quelle esposte dal TeamTecnico, sia relative a requisiti non chiari o di costoso ottenimento. In merito alla selezione delle varie alternative di soluzioni viene alla mente il film La vita è bella Cosa gradisce? Del maiale grasso grasso grasso con patate cotte in olio grasso grasso grasso oppure del salmone leggero leggero leggero con un insalata leggerissima?. Cosa sceglierà mai il cliente? La vocina presente nell autore afferma che molti clienti sceglierebbero comunque il maiale grasso grasso grasso respecttimeandcosts()

14 14 Capitolo 3. Introduzione agli Use Case Questo metodo può essere visto come lo speculare del metodo setrespect(): così come il TeamTecnico deve rispettare il cliente, allo stesso modo, quest ultimo deve rispettare la stima dei tempi e dei costi fornita dal TeamTecnico, e produrre ogni sforzo per limitare le proprie richieste di ridurre i tempi per la messa in opera del sistema. Quando le pressioni del cliente cominciano a essere eccessive, si vede la differenza tra capi progetto all altezza del proprio ruolo e quelli che credono che il capo progetto è colui che inserisce una serie di numeri nelle caselline del progetto realizzato per mezzo di Microsoft Project. Un altro problema tipico, che si verifica di sovente, è relativo al fatto che clienti/utenti desidererebbero esporre molto rapidamente, si intende, le funzionalità richieste, o magari addirittura solamente nominarle, per poi vedersele perfettamente incorporate nel sistema nell arco di qualche giorno. Come dire che i clienti tendono a non rispettare il processo di sviluppo del software adottato dal team tecnico. Da un lato si richiede elevata qualità e dall altro si pretende di ottenerla subito. setrequirementspriorities(priorities : RequirementsPriority[]) Su questo argomento si ritornerà più in dettaglio nel paragrafo dedicato al processo di sviluppo. Per adesso basti pensare che è necessario che il cliente corredi i vari requisiti con le relative priorità. È importante però sottolineare che queste devono ritenersi a carattere prettamente indicativo, in quanto l ordine con cui le varie funzionalità verranno realizzate deve dipendere dal piano di suddivisione del processo in iterazioni: è compito dell architetto e del capo progetto decidere tale piano in funzione anche di altri parametri, quali per esempio la riduzione dei rischi. reviewmodel() reviewprototype() Altro compito molto importante dei clienti consiste nel revisionare i modelli prodotti dal TeamTecnico. Spesso si tratta di un attività tediosa e non priva di elementi di frustrazione, però di importanza fondamentale per il processo di sviluppo del sistema. Una volta validati i vari modelli si prosegue con lo sviluppo del sistema ed eventuali errori nelle specifiche possono generare conseguenze notevoli. Chiaramente il colloquio tra il team tecnico e il cliente non si esaurisce qui: è sempre cosa buona e giusta chiedere ai clienti ulteriori chiarificazioni in caso di incertezze relative ai requisiti o proporre nuove idee. Ciò dovrebbe essere del tutto naturale: si assiste spesso a persone che volendo costruire la propria casa, cominciano non solo a visionare i vari progetti, ma anche a metterci le

15 UML e ingegneria del software: dalla teoria alla pratica 15 mani in prima persona. Chiaramente se dovesse accadere che, per esempio, la cucina risulti troppo piccola, sarebbe compito dell architetto, in funzione della propria esperienza, evidenziare l anomalia. Per ciò che concerne il metodo reviewprototype(), non ci sono dubbi: il cliente adora a sua volta giocare con i nuovi giocattoli e quindi sicuramente spenderà il tempo necessario, se non di più, per analizzare i prototipi in tutti i suoi dettagli. I limiti dei prototipi sono stati evidenziati nel capitolo precedente, e li si può sintetizzare riproponendo il commento di Stroustrup: il loro difetto principale è di somigliare terribilmente al sistema finale. notifychangerequirements() Questo metodo evidenzia una responsabilità fondamentale del cliente: comunicare i cambiamenti di specifiche non appena avvertiti. Nel caso in cui, eseguendo un incursione nella casa in costruzione, il cliente si accorga che la cucina è effettivamente troppo piccola, lo dovrebbe comunicare immediatamente senza attendere che i vari muri divisori siano edificati e che quindi una loro risistemazione diventi piuttosto gravosa se non impossibile. respectswdevelopmentprocess() Spesso una delle manchevolezze dei clienti è di non rispettare il processo di sviluppo del software, nel senso che loro tendenza naturale è di desiderare la botte piena e la moglie ubriaca: sistema di qualità corredato dai vari modelli e realizzato in un paio di fasi lunari. I sistemi software, alla stregua degli altri prodotti ingegneristici, prevedono opportune fasi e diversi modelli da produrre, ognuno dei quali richiede un certo quantitativo di tempo. Spesso sono gli stessi clienti che richiedono di codificare direttamente per poter giocare il prima possibile con il sistema. In ogni modo, il sogno dei clienti/utenti è di comunicare le funzioni da realizzare, magari semplicemente citandone il nome, e poi iniziare a effettuare i vari test dopo qualche giorno. Spesso palesare l inattuabilità di questo sogno diviene impossibile da parte di qualche commerciale di turno, ansioso forse di mascherare o farsi perdonare qualche marachella magari commessa in fase di fatturazione. La relativa decisione, a questo punto obbligatoria, di tenersi buono il cliente porta a promettere cose la cui portata esula assolutamente dalle reali possibilità Iterato poi il comportamento per un almeno un paio di generazioni, si ottiene la mutazione genetica anche dei clienti. D altronde si immagini di voler costruire la propria casa e per questo convocare due ditte edili per ottenere altrettanti preventivi. Si supponga ancora che l addetto commer-

16 16 Capitolo 3. Introduzione agli Use Case Figura 3.2 Rappresentazione schematica della proiezione statica della use case view. STATIC PERSPECTIVE USE CASE DIAGRAM ACTOR USE CASE VIEW USE CASE DINAMIC PERSPECTIVE DOCUMENT RELATIONSHIP DESIGN VIEW TEMPLATE SEQUENCE DIAGRAM COMPONENT VIEW ACTIVITY DIAGRAM IMPLEMENTATION VIEW DEPLOYMENT VIEW ciale della prima vi dica: Non c è problema, in un paio di settimane inizieremo i lavori. La mia azienda dispone di squadre di muratori e carpentieri che sono degli artisti. Lavoreranno come forsennati per consegnarvi la casa dopo sei mesi. Il tutto per un costo di centomila euro, migliaio in più o in meno. L addetto commerciale della seconda ditta, invece, vi dirà: In effetti è necessario capire che tipo di casa si vuole e quale sia conveniente costruire, verificare il terreno, esaminare il piano regolatore, realizzare qualche progetto di massima insieme. Solo allora sarà possibile una stima appropriata. In ogni modo lo studio iniziale di fattibilità le costerà sui cinquemila euro. Ora, quanti di voi affiderebbero la costruzione della casa alla seconda azienda? Use Cases View Le use case view (viste dei casi d uso) nei processi di sviluppo del software assumono un ruolo di primaria importanza, sia perché vengono sottoposte alla firma del cliente generalmente quella dei requisiti utente e, per la firma, si consiglia di richiedere l utilizzo del sangue come inchiostro, sia perché le restanti viste si occupano di modellare

17 UML e ingegneria del software: dalla teoria alla pratica 17 quanto specificato in quella dei requisiti. La proiezione statica della vista dei casi d uso si basa sugli omonimi diagrammi, frutto del lavoro svolto da Ivar Jacobson durante la sua collaborazione con la Ericsson nell ambito dello sviluppo di un sistema denominato AXE. Visto il successo riscosso dai diagrammi e percepitene le relative potenzialità, i Tres Amigos hanno pensato bene di inglobarli nello UML. Gli use case diagram sono utilizzati per dettagliare le funzionalità del sistema, dando particolare rilievo agli attori che interagiscono con esse. Le singole funzionalità vengono rappresentate graficamente attraverso elementi ellittici denominati use case. A questo punto si corre il rischio di fare confusione. In effetti, la prima vista logica, i relativi diagrammi, o meglio quelli che si occupano della proiezione statica, e alcuni elementi di questi ultimi, quelli che rappresentano le funzioni del sistema, si chiamano tutti, grazie a un sovrumano lavoro di fantasia, use case. Per tentare di far chiarezza si consideri il diagramma riportato in fig La prima vista è quindi composta da più diagrammi, di cui quelli derogati a modellarne la proiezione statica sono gli use case diagram, i quali permettono di specificare le funzioni del sistema per mezzo di elementi grafici a forma di ellissi detti use case. La vista dei casi d uso, come gran parte dei modelli, prevede due componenti: statica e dinamica, di cui solo la prima è rappresentabile per mezzo dei use case diagram. Quindi, al fine di colmare la lacuna e modellare anche la proiezione dinamica, fanno la loro apparizione gli interaction e activity diagram (diagrammi di interazione e diagrammi di attività), utilizzati per rappresentare particolari istanze dei casi d uso dette scenari. Entrambi sono oggetto di studio di appositi capitoli; per ora basti sapere che servono per modellare aspetti dinamici del sistema. Nei paragrafi seguenti si evidenzia che il ricorso a tali diagrammi, sebbene permetta di illustrare il comportamento dinamico delle funzioni del sistema, può risultare decisamente laborioso e non sempre di facile lettura. Probabilmente opportuni template dei casi d uso finiscono per essere lo strumento migliore: sono chiari, immediati e decisamente facili da aggiornare. Quando i diagrammi di interazione vengono utilizzati nella use cases view, ne realizzano gli scenario: versioni a elevato grado di astrazione dei flussi di azioni racchiusi nei casi d uso. Tipicamente, degli stessi diagrammi vengono realizzate versioni di maggior dettaglio nella design view allo scopo di rappresentare il flusso dei messaggi che gli oggetti si scambiano per produrre un determinato risultato. Semplificando al massimo il concetto, è possibile affermare la seguente proporzione: gli scenari stanno agli use case come gli oggetti stanno alle classi. Talune volte può capitare di incontrare in opportune versioni degli use case view anche diagrammi delle classi: ciò è una buona norma a patto che il grado di astrazione degli stessi rimanga al livello concettuale e che le classi identificate siano quelle appartenenti al mondo reale e non all infrastruttura del sistema (si parla di modello del dominio). L obiettivo è quello di modellare e quindi studiare le relazioni esistenti tra le varie entità presenti nell area di business del cliente (dominio del problema).

18 18 Capitolo 3. Introduzione agli Use Case A lavoro concluso, i diagrammi dei casi d uso devono rappresentare tutte le funzioni del sistema, a partire dal relativo avvio, o richiesta, che tipicamente viene generata da un attore del sistema, fino alla relativa conclusione. Le proprietà che tutti i modelli dovrebbero possedere (accuratezza, consistenza, semplicità e manutenibilità) in questo contesto assumono un importanza imprescindibile. Gli attori, sono entità esterne al sistema che hanno interesse a interagire con esso. Pertanto, contrariamente a quanto lascerebbe pensare il nome, e a memorie derivanti da metodologie quali DFD (Data Flow Diagram, diagramma del flusso dei dati), gli attori sono sia persone fisiche, sia sistemi o dispositivi hardware che interagiscono con il sistema. Va sottolineato, per l ennesima volta, che a questo livello di analisi, il sistema va visto come una scatola nera, pertanto si deve descrivere cosa fa il sistema senza specificare il come: ci si deve occupare dello spazio del problema e non di quello delle soluzioni. L impegno è proprio nel cercare di isolarsi, di astrarsi il più possibile da dettagli realizzativi il cui studio è demandato alle apposite fasi. Perché utilizzare i diagrammi dei casi d uso?. L interrogazione posta nel titolo potrebbe risultare piuttosto retorica e la risposta piuttosto convenzionale potrebbe essere: perché fanno parte dello UML. Allora si provi a porla in questi termini perché i Tres Amigos hanno inserito i diagrammi dei casi d uso nello UML? Quali sono i vantaggi?. Molto brevemente le principali peculiarità dei casi d uso possono ricondursi ai seguenti punti: si tratta di uno strumento facilmente comprensibile dagli utenti e quindi appropriato per comunicare con essi e per ottenere le necessarie validazioni. si prestano a essere utilizzati con diversi livelli di formalità. Generalmente, nella primissime fasi si è concentrati nel comprendere più intimamente le necessità dell utente e quindi si conferisce minore importanza ai principi dell Object Oriented, anche perché spesso non facilmente comprensibili dall utente medio. Nelle fasi successive invece si è anche coinvolti nel processo di sviluppo del sistema e quindi il livello di formalità deve essere necessariamente elevato. permettono di definire molto chiaramente i confini del sistema e di evidenziarne gli attori sia umani che non. evidenziano il comportamento del sistema, permettendo di evidenziare eventuali incoerenze e lacune nell analisi dei requisiti.

19 UML e ingegneria del software: dalla teoria alla pratica 19 permettono di realizzare un ottima documentazione. i casi d uso opportunamente strutturati si prestano a essere utilizzati come scenari di test (i test case). Fruitori della use case view La vista dei casi d uso è oggetto di interesse per un vasto insieme di figure professionali coinvolte nel ciclo di vita del sistema: dai clienti ai capi progetto, dagli architetti ai tester, dagli addetti al marketing ai commerciali e così via. I primi, in ordine cronologico, a fruire della vista dei casi d uso sono i clienti, i capi progetto e i business analysts: le use case view specificano le funzionalità che il sistema dovrà realizzare e come queste verranno fruite. In quest ottica le viste sono necessarie per riuscire a carpire i requisiti utente: reali necessità, sogni più o meno consci, eventuali reticenze In molte organizzazioni sono previsti opportuni team che si occupano unicamente di analizzare l attività economica del cliente, di capire i requisiti del sistema e di redigere il documento dei requisiti. Sono i padroni della use case view. Queste figure professionali vengono tipicamente denominate business analysts. La vista dei casi d uso è necessaria poi al team degli sviluppatori (architetti, disegnatori, codificatori) poiché fornisce direttive, chiare e precise un sogno su come realizzare il modello. In questo contesto, con il termine di architetti si fa riferimento a quelli software, ossia a coloro che si occupano di disegnare il sistema in termini di classi. Ovviamente anche gli architetti hardware hanno interesse a fruire della vista degli use case perché fornisce le prime disposizioni su come organizzare il sistema in termini di dispositivi fisici (server, connessioni, proxy, ecc.). Come si avrà modo di vedere nel capitolo dedicato, nei processi di sviluppo use case driven e architecture centric esiste una mutua dipendenza tra la use case view e la vista fisica del sistema: le funzionalità da realizzare forniscono l orientamento iniziale su come organizzare l infrastruttura hardware così come quest ultima influenza la modalità con la quale le diverse funzioni possono essere fruite. Da tener presente che la proiezione dinamica oltre a dettagliare la sequenza di azioni da svolgere, nel caso in cui tutto funzioni correttamente, dovrebbe riportare anche la casistica completa degli inconvenienti che potrebbero verificarsi durante l esecuzione del caso d uso e le relative contromisure che il sistema dovrebbe attuare come risposta. Pertanto durante la progettazione e l implementazione del sistema, il team di sviluppatori dovrebbe aver ben presente i casi d uso a cui si riferisce la parte del sistema oggetto di disegno o implementazione. Altra categoria di utilizzatori è costituita dalle persone che dovranno effettuare le verifiche finali (note anche come test di sistema): l utilizzo di tale vista consente di verificare che il sistema prodotto realizzi pienamente ciò che è stato sancito con il cliente.

20 20 Capitolo 3. Introduzione agli Use Case Sebbene in molte organizzazioni i test vengano eseguiti solo dagli sviluppatori e dall organizzazione presente presso il committente, nelle organizzazioni più strutturate sono previsti appositi team (detti martellatori in quanto il loro obiettivo è prendere a martellate il sistema ) che si occupano della delicata fase di test. In generale, non è un buon principio far eseguire i test allo stesso personale che ha prodotto lo specifico artifact: i programmatori non dovrebbero essere i soli a verificare il proprio codice. Il problema è che chi realizza un prodotto tende, inconsciamente, a trascurare verifiche di situazioni critiche e meno chiare che, per questo, divengono più soggette a errori. A tal fine, chi effettua i test deve possedere una buona conoscenza dei requisiti utente e quindi della use case view. A dire il vero, solo per la fase di test, si dovrebbero realizzare apposite versioni delle use case view denominate test case. Dall elenco dei fruitori si vogliono poi escludere i commerciali? Ma certo che no. Anzi, sarebbe auspicabile che taluni commerciali e addetti al marketing dessero un occhiata a quanto prodotto, giusto quel tanto che basta per capire di cosa dovranno parlare nelle varie riunioni con i clienti ed evitare di basare i propri giudizi unicamente sulla scelta dei colori presenti nelle interfacce utente. Si potrebbe addirittura correre il rischio di evitare di vendere congelatori agli esquimesi ed impianti di riscaldamento a chi vive all equatore. Oppure potrebbero evitarsi frasi del tipo Perché ci vuole così tanto a realizzare un sistema?. Ma chi glielo fa fare di stare a competere con questi tecnici paranoici e schizoidi? In fondo, esistono centinaia di lavori migliori di questo Gestire un banco di frutta è difficile, le mele hanno la brutta abitudine di andare a male Troppo complicato, è meglio il software, lì si può buttare tutto in caciara e un responsabile esterno si riesce sempre a trovarlo. Processo di sviluppo, useless case e IDP Il processo di sviluppo del software è una delle risorse come tale dovrebbe essere considerato più importanti delle aziende produttrici di software: tra le varie caratteristiche, fornisce al progettista e ai vari elementi del team direttive precise su cosa fare, quando farlo, come, dove e perché. In sintesi la corretta adozione di un processo, da sola, può fare la differenza tra un progetto di buona riuscita e un insuccesso. Sebbene non esista il processo valido in assoluto o che risulta ottimale per ogni progetto, non sono infrequenti aziende software che si affidano al famoso processo di sviluppo denominato IDP (Irrational Development Process, processo di sviluppo irrazionale), tipicamente composto da tre fasi: 1. analisi dei requisiti;

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto LA PROGETTAZIONE 1 LA PROGETTAZIONE Oggi il raggiungimento di un obiettivo passa per la predisposizione di un progetto. Dal mercato al terzo settore passando per lo Stato: aziende, imprese, organizzazioni,

Dettagli

GUIDA ALLA RELAZIONE CON I FORNITORI

GUIDA ALLA RELAZIONE CON I FORNITORI GUIDA ALLA RELAZIONE CON I FORNITORI Indice 1 Introduzione 2 2 Come ERA collabora con i fornitori 3 Se siete il fornitore attualmente utilizzato dal cliente Se siete dei fornitori potenziali Se vi aggiudicate

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

risparmio, dove lo metto ora? le risposte alle domande che i risparmiatori si pongono sul mondo dei fondi

risparmio, dove lo metto ora? le risposte alle domande che i risparmiatori si pongono sul mondo dei fondi il risparmio, dove lo ora? metto le risposte alle domande che i risparmiatori si pongono sul mondo dei fondi Vademecum del risparmiatore le principali domande emerse da una recente ricerca di mercato 1

Dettagli

John Dewey. Le fonti di una scienza dell educazione. educazione

John Dewey. Le fonti di una scienza dell educazione. educazione John Dewey Le fonti di una scienza dell educazione educazione 1929 L educazione come scienza indipendente Esiste una scienza dell educazione? Può esistere una scienza dell educazione? Ṫali questioni ineriscono

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali LAVORO DI GRUPPO Caratteristiche dei gruppi di lavoro transnazionali Esistono molti manuali e teorie sulla costituzione di gruppi e sull efficacia del lavoro di gruppo. Un coordinatore dovrebbe tenere

Dettagli

Il modello metodologico del Sistema di Misurazione e Valutazione della sicurezza aziendale (MVS)

Il modello metodologico del Sistema di Misurazione e Valutazione della sicurezza aziendale (MVS) Il modello metodologico del Sistema di Misurazione e Valutazione della sicurezza aziendale (MVS) >> Il Sistema MVS permette di misurare e valutare la sicurezza aziendale (nell accezione di Security) nei

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

Definizione e struttura della comunicazione

Definizione e struttura della comunicazione Definizione e struttura della comunicazione Sono state date molteplici definizioni della comunicazione; la più semplice e comprensiva è forse questa: passaggio di un'informazione da un emittente ad un

Dettagli

Guida alle offerte di finanziamento per le medie imprese

Guida alle offerte di finanziamento per le medie imprese IBM Global Financing Guida alle offerte di finanziamento per le medie imprese Realizzata da IBM Global Financing ibm.com/financing/it Guida alle offerte di finanziamento per le medie imprese La gestione

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

Che cos è un focus-group?

Che cos è un focus-group? Che cos è un focus-group? Si tratta di interviste di tipo qualitativo condotte su un ristretto numero di persone, accuratamente selezionate, che vengono riunite per discutere degli argomenti più svariati,

Dettagli

CELTA IUSTA. Cosa, come, quando, quanto e perché: quello che dovresti sapere per investire i tuoi risparmi

CELTA IUSTA. Cosa, come, quando, quanto e perché: quello che dovresti sapere per investire i tuoi risparmi ONDI OMUNI: AI A CELTA IUSTA Cosa, come, quando, quanto e perché: quello che dovresti sapere per investire i tuoi risparmi CONOSCERE I FONDI D INVESTIMENTO, PER FARE SCELTE CONSAPEVOLI I fondi comuni sono

Dettagli

Il mondo in cui viviamo

Il mondo in cui viviamo Il mondo in cui viviamo Il modo in cui lo vediamo/ conosciamo Dalle esperienze alle idee Dalle idee alla comunicazione delle idee Quando sono curioso di una cosa, matematica o no, io le faccio delle domande.

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Mario Polito IARE: Press - ROMA

Mario Polito IARE: Press - ROMA Mario Polito info@mariopolito.it www.mariopolito.it IMPARARE A STUD IARE: LE TECNICHE DI STUDIO Come sottolineare, prendere appunti, creare schemi e mappe, archiviare Pubblicato dagli Editori Riuniti University

Dettagli

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO QUESTIONARIO SUGLI STILI DI APPRENDIMENTO Le seguenti affermazioni descrivono alcune abitudini di studio e modi di imparare. Decidi in quale misura ogni affermazione si applica nel tuo caso: metti una

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Erwin Schrödinger Che cos è la vita? La cellula vivente dal punto di vista fisico tr. it. a cura di M. Ageno, Adelphi, Milano 2008, pp.

Erwin Schrödinger Che cos è la vita? La cellula vivente dal punto di vista fisico tr. it. a cura di M. Ageno, Adelphi, Milano 2008, pp. RECENSIONI&REPORTS recensione Erwin Schrödinger Che cos è la vita? La cellula vivente dal punto di vista fisico tr. it. a cura di M. Ageno, Adelphi, Milano 2008, pp. 154, 12 «Il vasto e importante e molto

Dettagli

PRESENTARE UN IDEA PROGETTUALE

PRESENTARE UN IDEA PROGETTUALE PRESENTARE UN IDEA PROGETTUALE LINEE GUIDA PER UNA EFFICACE PRESENTAZIONE DI UN BUSINESS PLAN INTRODUZIONE ALLA GUIDA Questa breve guida vuole indicare in maniera chiara ed efficiente gli elementi salienti

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

Regole per un buon Animatore

Regole per un buon Animatore Regole per un buon Animatore ORATORIO - GROSOTTO Libretto Animatori Oratorio - Grosotto Pag. 1 1. Convinzione personale: fare l animatore è una scelta di generoso servizio ai ragazzi per aiutarli a crescere.

Dettagli

1 Il criterio Paretiano e la "Nuova economia del Benessere"

1 Il criterio Paretiano e la Nuova economia del Benessere 1 Il criterio Paretiano e la "Nuova economia del Benessere" 1.1 L aggregazione di preferenze ordinali inconfrontabili e il criterio di Pareto L aggregazione delle preferenze individuali è problematica

Dettagli

MAURIZIO ABBATI STRUMENTI UTILI PER CAMBIARE E MIGLIORARE. HOUSE ORGAN AZIENDALE Guida alla creazione di un magazine interno

MAURIZIO ABBATI STRUMENTI UTILI PER CAMBIARE E MIGLIORARE. HOUSE ORGAN AZIENDALE Guida alla creazione di un magazine interno MAURIZIO ABBATI STRUMENTI UTILI PER CAMBIARE E MIGLIORARE HOUSE ORGAN AZIENDALE Guida alla creazione di un magazine interno Indice 01. 02. 03. I tipi di house organ Dall idea al progetto I contenuti A

Dettagli

LA PROGETTAZIONE SECONDO LA ISO 9001: 2000 (Giorgio Facchetti)

LA PROGETTAZIONE SECONDO LA ISO 9001: 2000 (Giorgio Facchetti) LA PROGETTAZIONE SECONDO LA ISO 9001: 2000 (Giorgio Facchetti) Uno degli incubi più ricorrenti per le aziende certificate l applicazione del requisito relativo alla progettazione in occasione dell uscita

Dettagli

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Università degli Studi di Parma Dipartimento di Matematica e Informatica Corso di Laurea in Informatica DISPENSE INTRODUTTIVE INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Prof. Giulio Destri

Dettagli

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

Dettagli

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale DIIGA - Università Politecnica delle Marche A.A. 2006/2007 Informatica Industriale Modello funzionale: Informazione Progettazione concettuale Luca Spalazzi spalazzi@diiga.univpm.it www.diiga.univpm.it/~spalazzi/

Dettagli

1. QUAL È LO SCOPO DI QUESTO MODULO?

1. QUAL È LO SCOPO DI QUESTO MODULO? Percorso B. Modulo 4 Ambienti di Apprendimento e TIC Guida sintetica agli Elementi Essenziali e Approfondimenti (di Antonio Ecca), e slide per i formatori. A cura di Alberto Pian (alberto.pian@fastwebnet.it)

Dettagli

Business Process Reengineering

Business Process Reengineering Business Process Reengineering AMMISSIONE ALL'ESAME DI LAUREA Barbagallo Valerio Da Lozzo Giordano Mellini Giampiero Introduzione L'oggetto di questo lavoro riguarda la procedura di iscrizione all'esame

Dettagli

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Forniamo in questo articolo le risposte ai 53 quesiti ricevuti

Dettagli

Su gentile concessione di D&L - Rivista Critica di Diritto del Lavoro. Le riforme del contratto a termine: non solo Legge Fornero.

Su gentile concessione di D&L - Rivista Critica di Diritto del Lavoro. Le riforme del contratto a termine: non solo Legge Fornero. Le riforme del contratto a termine: non solo Legge Fornero Milano, 31/1/13 1. Premessa - 2. L art. 32 L. 183/10-3. La riforma Fornero - L art. 28 DL 179/12. 1. Premessa Il contratto a termine detiene un

Dettagli

capitolo 6 IL QUESTIONARIO PER LA VALUTV ALUTAZIONEAZIONE DEI CONTENUTI

capitolo 6 IL QUESTIONARIO PER LA VALUTV ALUTAZIONEAZIONE DEI CONTENUTI capitolo 6 IL QUESTIONARIO PER LA VALUTV ALUTAZIONEAZIONE DEI CONTENUTI 6.1 ISTRUZIONI PER IL VALUTATORE Il processo di valutazione si articola in quattro fasi. Il Valutatore deve: 1 leggere il questionario;

Dettagli

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza PROCESS MAPPING (2) Approcci: 2- Identificazione del processo Esaustivo (o dei processi) da analizzare Mappatura a largo spettro (es.: vasta implementazione di un ERP) In relazione al problema ad es. i

Dettagli

COME ALLENERO QUEST ANNO?

COME ALLENERO QUEST ANNO? COME ALLENERO QUEST ANNO? Io sono fatto così!!! Io ho questo carattere!!! Io sono sempre stato abituato così!!!! Io ho sempre fatto così!!!!!! Per me va bene così!!!!! Io la penso così!!! Quando si inizia

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Trieste, 25 ottobre 2006

Trieste, 25 ottobre 2006 Trieste, 25 ottobre 2006 PRESENTAZIONE DEL BILANCIO DI SOSTENIBILITÀ 2005 DEL GRUPPO GENERALI AGLI STUDENTI DELL UNIVERSITA DI TRIESTE INTERVENTO DELL AMMINISTRATORE DELEGATO GIOVANNI PERISSINOTTO Vorrei

Dettagli

Qualificare i fornitori attraverso un sistema analitico di rating

Qualificare i fornitori attraverso un sistema analitico di rating articolo n. 3 giugno 2014 Qualificare i fornitori attraverso un sistema analitico di rating MASSIMILIANO MARI Responsabile Acquisti, SCANDOLARA s.p.a. Realizzare un sistema di rating costituisce un attività

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING

STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING Gianna Maria Agnelli Psicologa Clinica e Psicoterapeuta Clinica del Lavoro "Luigi Devoto Fondazione IRCCS Ospedale

Dettagli

Partenariato transatlantico su commercio e investimenti. Parte normativa

Partenariato transatlantico su commercio e investimenti. Parte normativa Partenariato transatlantico su commercio e investimenti Parte normativa settembre 2013 2 I presidenti Barroso, Van Rompuy e Obama hanno chiarito che la riduzione delle barriere normative al commercio costituisce

Dettagli

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA ROMA 20-22 OTTOBRE 2014 RESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli:

Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli: 2. IL PROCESSO DI VALUTAZIONE 2.1. Gli attori del processo di valutazione Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli: Direttore dell Agenzia delle Entrate.

Dettagli

SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL?

SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL? archiviazione ottica, conservazione e il protocollo dei SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL? Il software Facile! BUSINESS Organizza l informazione

Dettagli

Il pomeriggio dello studente dislessico alle superiori: il ragazzo, la famiglia, lo studio, i compiti

Il pomeriggio dello studente dislessico alle superiori: il ragazzo, la famiglia, lo studio, i compiti Il pomeriggio dello studente dislessico alle superiori: il ragazzo, la famiglia, lo studio, i compiti Relatore: Prof.ssa Chiara Frassineti, genitore e insegnante Il rapporto tra genitori e ragazzo (studente)

Dettagli

Il CIO del futuro Report sulla ricerca

Il CIO del futuro Report sulla ricerca Il CIO del futuro Report sulla ricerca Diventare un promotore di cambiamento Condividi questo report Il CIO del futuro: Diventare un promotore di cambiamento Secondo un nuovo studio realizzato da Emerson

Dettagli

Ottimizzare gli sconti per incrementare i profitti

Ottimizzare gli sconti per incrementare i profitti Ottimizzare gli sconti per incrementare i profitti Come gestire la scontistica per massimizzare la marginalità di Danilo Zatta www.simon-kucher.com 1 Il profitto aziendale è dato da tre leve: prezzo per

Dettagli

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Release Management Obiettivi Obiettivo del Release Management è di raggiungere una visione d insieme del cambiamento nei servizi IT e accertarsi che tutti gli aspetti di una release (tecnici e non) siano

Dettagli

Chimica Suggerimenti per lo studio

Chimica Suggerimenti per lo studio Chimica Suggerimenti per lo studio Dr. Rebecca R. Conry Traduzione dall inglese di Albert Ruggi Metodo di studio consigliato per la buona riuscita degli studi in Chimica 1 Una delle cose che rende duro

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi IL GESTIONALE DEL FUTURO L evoluzione del software per l azienda moderna Gestirsi / Capirsi / Migliorarsi IL MERCATO ITALIANO L Italia è rappresentata da un numero elevato di piccole e medie aziende che

Dettagli

a cura della Commissione di diritto societario dell Ordine dei dottori commercialisti e degli esperti contabili di Milano

a cura della Commissione di diritto societario dell Ordine dei dottori commercialisti e degli esperti contabili di Milano La ricostituzione della pluralità dei soci nella s.a.s. In ogni numero della rivista trattiamo una questione dibattuta a cui i nostri esperti forniscono una soluzione operativa. Una guida indispensabile

Dettagli

MANUALE OPERATIVO INTRODUZIONE. Manuale Operativo

MANUALE OPERATIVO INTRODUZIONE. Manuale Operativo Pagina 1 di 24 INTRODUZIONE SEZ 0 Manuale Operativo DOCUMENTO TECNICO PER LA CERTIFICAZIONE DEL PROCESSO DI VENDITA DEGLI AGENTI E RAPPRESENTANTI DI COMMERCIO OPERANTI PRESSO UN AGENZIA DI RAPPRESENTANZA:

Dettagli

Perché i nostri bambini siano protetti il meglio possibile. Commissione europea Imprese e industria

Perché i nostri bambini siano protetti il meglio possibile. Commissione europea Imprese e industria LA SICUREZZA DEI GIOCATTOLI Perché i nostri bambini siano protetti il meglio possibile Commissione europea Imprese e industria Fotolia Orange Tuesday L Unione europea (UE) conta circa 80 milioni di bambini

Dettagli

Le classi 4^A e B di Scarperia hanno richiesto e partecipato al PROGETTO CLOWN. L esperienza, che è stata ritenuta molto positiva dalle insegnanti,

Le classi 4^A e B di Scarperia hanno richiesto e partecipato al PROGETTO CLOWN. L esperienza, che è stata ritenuta molto positiva dalle insegnanti, Le classi 4^A e B di Scarperia hanno richiesto e partecipato al PROGETTO CLOWN. L esperienza, che è stata ritenuta molto positiva dalle insegnanti, si è conclusa con una lezione aperta per i genitori.

Dettagli

Indagine sull utilizzo di Internet a casa e a scuola

Indagine sull utilizzo di Internet a casa e a scuola Indagine sull utilizzo di Internet a casa e a scuola Realizzata da: Commissionata da: 1 INDICE 1. Metodologia della ricerca Pag. 3 2. Genitori e Internet 2.1 L utilizzo del computer e di Internet in famiglia

Dettagli

Elaidon Web Solutions

Elaidon Web Solutions Elaidon Web Solutions Realizzazione siti web e pubblicità sui motori di ricerca Consulente Lorenzo Stefano Piscioli Via Siena, 6 21040 Gerenzano (VA) Telefono +39 02 96 48 10 35 elaidonwebsolutions@gmail.com

Dettagli

Guido Candela, Paolo Figini - Economia del turismo, 2ª edizione

Guido Candela, Paolo Figini - Economia del turismo, 2ª edizione 8.2.4 La gestione finanziaria La gestione finanziaria non dev essere confusa con la contabilità: quest ultima, infatti, ha come contenuto proprio le rilevazioni contabili e il reperimento dei dati finanziari,

Dettagli

Sistemi di supporto alle decisioni

Sistemi di supporto alle decisioni Sistemi di supporto alle decisioni Introduzione I sistemi di supporto alle decisioni, DSS (decision support system), sono strumenti informatici che utilizzano dati e modelli matematici a supporto del decision

Dettagli

I CHIARIMENTI DELL AGENZIA DELLE ENTRATE SUL REVERSE CHARGE

I CHIARIMENTI DELL AGENZIA DELLE ENTRATE SUL REVERSE CHARGE I CHIARIMENTI DELL AGENZIA DELLE ENTRATE SUL REVERSE CHARGE Circolare del 31 Marzo 2015 ABSTRACT Si fa seguito alla circolare FNC del 31 gennaio 2015 con la quale si sono offerte delle prime indicazioni

Dettagli

L attività di ricerca e sviluppo nell organizzazione aziendale

L attività di ricerca e sviluppo nell organizzazione aziendale CAPITOLO PRIMO L attività di ricerca e sviluppo nell organizzazione aziendale SOMMARIO * : 1. Il ruolo dell innovazione tecnologica 2. L attività di ricerca e sviluppo: contenuti 3. L area funzionale della

Dettagli

QUALE SIGNIFICATO HA LA FIRMA DEL PDP DA PARTE DELLO STUDENTE / GENITORE E DEI DOCENTI?

QUALE SIGNIFICATO HA LA FIRMA DEL PDP DA PARTE DELLO STUDENTE / GENITORE E DEI DOCENTI? FAQ: AREA DELLA PROGRAMMAZIONE (PDP) QUAL È LA NORMATIVA DI RIFERIMENTO SUI DSA NELLA SCUOLA? Al momento è in vigore la Legge 170 che regola in modo generale i diritti delle persone con DSA non soltanto

Dettagli

TECNICHE. H. Sei Cappelli per Pensare. 1. Che cos è la tecnica dei sei cappelli per pensare?

TECNICHE. H. Sei Cappelli per Pensare. 1. Che cos è la tecnica dei sei cappelli per pensare? TECNICHE H. Sei Cappelli per Pensare 1. Che cos è la tecnica dei sei cappelli per pensare? Il metodo dei sei cappelli per pensare è stato inventato da Edward de Bono nel 1980. I cappelli rappresentano

Dettagli

di Sara Baroni Marketing e Vendite >> Marketing e Management

di Sara Baroni Marketing e Vendite >> Marketing e Management GESTIRE CON SUCCESSO UNA TRATTATIVA COMMERCIALE di Sara Baroni Marketing e Vendite >> Marketing e Management OTTENERE FIDUCIA: I SEI LIVELLI DI RESISTENZA Che cosa comprano i clienti? Un prodotto? Un servizio?

Dettagli

I CRITERI DI VALUTAZIONE DELLE POSTE DI BILANCIO: una breve disamina sul fair value

I CRITERI DI VALUTAZIONE DELLE POSTE DI BILANCIO: una breve disamina sul fair value I CRITERI DI VALUTAZIONE DELLE POSTE DI BILANCIO: una breve disamina sul fair value A cura Alessio D'Oca Premessa Nell ambito dei principi che orientano la valutazione del bilancio delle società uno dei

Dettagli

Introduzione al GIS (Geographic Information System)

Introduzione al GIS (Geographic Information System) Introduzione al GIS (Geographic Information System) Sommario 1. COS E IL GIS?... 3 2. CARATTERISTICHE DI UN GIS... 3 3. COMPONENTI DI UN GIS... 4 4. CONTENUTI DI UN GIS... 5 5. FASI OPERATIVE CARATTERIZZANTI

Dettagli

VALUTAZIONE DI RISULTATO E DI IMPATTO del progetto Diesis

VALUTAZIONE DI RISULTATO E DI IMPATTO del progetto Diesis Obiettivo Competitività Regionale e Occupazione Programma Operativo Nazionale Azioni di Sistema (FSE) 2007-2013 [IT052PO017] Obiettivo Convergenza Programma Operativo Nazionale Governance e Azioni di Sistema

Dettagli

Norme per la preparazione di sentenze da pubblicarsi ne «IL FORO ITALIANO»

Norme per la preparazione di sentenze da pubblicarsi ne «IL FORO ITALIANO» Norme per la preparazione di sentenze da pubblicarsi ne «IL FORO ITALIANO» ROMA SOCIETÀ EDITRICE DEL «FORO ITALIANO» 1969 (2014) Norme per la preparazione di sentenze da pubblicarsi ne «IL FORO ITALIANO»

Dettagli

PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA

PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA DIRETTIVA DEL MINISTRO DELLA FUNZIONE PUBBLICA SULLA RILEVAZIONE DELLA QUALITA PERCEPITA DAI CITTADINI A tutti i Ministeri - Uffici

Dettagli

«Abbiamo un margine di manovra sufficiente»

«Abbiamo un margine di manovra sufficiente» Conferenza stampa annuale del 17 giugno 2014 Anne Héritier Lachat, presidente del Consiglio di amministrazione «Abbiamo un margine di manovra sufficiente» Gentili Signore, egregi Signori, sono ormai trascorsi

Dettagli

ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA

ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA L allievo partecipa a scambi comunicativi (conversazione, discussione di classe o di gruppo) con compagni e insegnanti

Dettagli

Alcolismo: anche la famiglia e gli amici sono coinvolti

Alcolismo: anche la famiglia e gli amici sono coinvolti Alcolismo: anche la famiglia e gli amici sono coinvolti Informazioni e consigli per chi vive accanto ad una persona con problemi di alcol L alcolismo è una malattia che colpisce anche il contesto famigliare

Dettagli

Metodologie di comunicazione con persone disabili

Metodologie di comunicazione con persone disabili Metodologie di comunicazione con persone disabili Eleonora Castagna Terapista della Neuropsicomotricità dell Età Evolutiva Antonia Castelnuovo Psicomotricista Villa Santa Maria, Tavernerio Polo Territoriale

Dettagli

I beni pubblici come causa del fallimento del mercato. Definizioni e caratteristiche

I beni pubblici come causa del fallimento del mercato. Definizioni e caratteristiche I beni pubblici come causa del fallimento del mercato. Definizioni e caratteristiche (versione provvisoria) Marisa Faggini Università di Salerno mfaggini@unisa.it I beni pubblici rappresentano un esempio

Dettagli

La Valutazione Euristica

La Valutazione Euristica 1/38 E un metodo ispettivo di tipo discount effettuato da esperti di usabilità. Consiste nel valutare se una serie di principi di buona progettazione sono stati applicati correttamente. Si basa sull uso

Dettagli

OSSERVAZIONI AL REGOLAMENTO IN PUBBLICA CONSULTAZIONE

OSSERVAZIONI AL REGOLAMENTO IN PUBBLICA CONSULTAZIONE OSSERVAZIONI AL REGOLAMENTO IN PUBBLICA CONSULTAZIONE Quest Associazione apprezza la decisione dell ISVAP di avviare la procedura per la revisione del regolamento n.5/2006, sull attività degli intermediari

Dettagli

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate 6.1 Metodi per lo sviluppo di nuovi prodotti (MSNP) Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate Questo capitolo presenta alcune metodologie per gestire al meglio

Dettagli

IL RAPPORTO CON GLI ALTRI

IL RAPPORTO CON GLI ALTRI IL RAPPORTO CON GLI ALTRI Cos è la vita?, è una domanda che molti si pongono. La vita è rapporto, amici miei. Possono essere date altre risposte, e tutte potrebbero essere valide, ma al di là di tutto,

Dettagli

1. non intraprendere trattative di affari con operatori senza prima aver raccolto informazioni sull esistenza e l affidabilita della controparte;

1. non intraprendere trattative di affari con operatori senza prima aver raccolto informazioni sull esistenza e l affidabilita della controparte; CAUTELE NELLE TRATTATIVE CON OPERATORI CINESI La Cina rappresenta in genere un partner commerciale ottimo ed affidabile come dimostrato dagli straordinari dati di interscambio di questo Paese con il resto

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

un occhio al passato per il tuo business futuro

un occhio al passato per il tuo business futuro 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 un occhio al passato per il tuo business futuro BUSINESS DISCOVERY Processi ed analisi per aziende virtuose Che cos è La Business Discovery è un insieme

Dettagli

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu FRAUD MANAGEMENT. COME IDENTIFICARE E COMB BATTERE FRODI PRIMA CHE ACCADANO LE Con una visione sia sui processi di business, sia sui sistemi, Reply è pronta ad offrire soluzioni innovative di Fraud Management,

Dettagli