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

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

6 IL RUOLO DEL FINANZIAMENTO PUBBLICO

6 IL RUOLO DEL FINANZIAMENTO PUBBLICO 6 IL RUOLO DEL FINANZIAMENTO PUBBLICO Nel comprendere le strategie formative adottate dalle grandi imprese assume una particolare rilevanza esaminare come si distribuiscano le spese complessivamente sostenute

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Sommario. DOCUMENTO RISERVATO AD USO INTERNO Pagina 2 di 10

Sommario. DOCUMENTO RISERVATO AD USO INTERNO Pagina 2 di 10 Piano di valutazione Horsa Anno 2013 Sommario Perché Horsa introduce un Piano di Valutazione... 3 I destinatari del Piano di Valutazione... 4 I criteri di acquisizione dei Punti... 4 Costi standard di

Dettagli

Il Controllo di gestione nella piccola impresa

Il Controllo di gestione nella piccola impresa Stampa Il Controllo di gestione nella piccola impresa admin in A cura di http://www.soluzionipercrescere.com La piccola impresa presenta generalmente un organizzazione molto snella dove l imprenditore

Dettagli

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

TECNICO DELLA PIANIFICAZIONE ECONOMICA E AMBIENTALE DELLE AREE PORTUALI

TECNICO DELLA PIANIFICAZIONE ECONOMICA E AMBIENTALE DELLE AREE PORTUALI TECNICO DELLA PIANIFICAZIONE ECONOMICA E AMBIENTALE DELLE AREE PORTUALI LEZIONE 6/10/05 STATISTICA Antigone Marino LE FASI DI REALIZZAZIONE DI UNA RICERCA 1. Definizione del tipo di informazioni attese

Dettagli

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano.

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. di: Enrico MASTROFINI Ottobre 2004 Nella formulazione iniziale del Piano Ict sono di solito inseriti

Dettagli

GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA

GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA 1 SOMMARIO PREMESSA... 3 LE CONSIDERAZIONI STRATEGICHE DA FARE SUI FORNITORI... 4 CONCENTRARSI SUGLI OBIETTIVI... 4 RIDURRE

Dettagli

Customer satisfaction

Customer satisfaction [moduli operativi di formazione] Customer satisfaction Soddisfare Migliorare Continuare a soddisfare CUSTOMER SATISFACTION Tutte le aziende dipendono dai propri clienti ed è indispensabile agire per capire

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Dott.ssa GIULIA CANDIANI. (Coordinatore Settore Sanità Associazione Altroconsumo)

Dott.ssa GIULIA CANDIANI. (Coordinatore Settore Sanità Associazione Altroconsumo) Dott.ssa GIULIA CANDIANI (Coordinatore Settore Sanità Associazione Altroconsumo) Innanzitutto due parole di presentazione: Altroconsumo è una associazione indipendente di consumatori, in cui io lavoro

Dettagli

IL COUNSELING NELLE PROFESSIONI D AIUTO

IL COUNSELING NELLE PROFESSIONI D AIUTO IL COUNSELING NELLE PROFESSIONI D AIUTO Obiettivi: Conoscere le peculiarità del counseling nelle professioni d aiuto Individuare le abilità del counseling necessarie per svolgere la relazione d aiuto Analizzare

Dettagli

2. e i risultati che si vogliono conseguire

2. e i risultati che si vogliono conseguire L obiettivo di questo intervento consiste nel mostrare come trarre la massima efficienza nelle operazioni multi-canale di vendita e sincronizzazione online. Per efficienza si intende la migliore coniugazione

Dettagli

PAGAMI ADESSO! COME RECUPERARE I TUOI CREDITI IN MODO FACILE E SENZA CONFLITTI. In questo manuale viene trattato l argomento del recupero crediti.

PAGAMI ADESSO! COME RECUPERARE I TUOI CREDITI IN MODO FACILE E SENZA CONFLITTI. In questo manuale viene trattato l argomento del recupero crediti. PAGAMI ADESSO! COME RECUPERARE I TUOI CREDITI IN MODO FACILE E SENZA CONFLITTI In questo manuale viene trattato l argomento del recupero crediti. In modo rapido ma efficace saranno esaminati gli aspetti

Dettagli

Istituto Comprensivo Scuola dell Infanzia, Primaria e Secondaria di I Grado 86048 Sant Elia a Pianisi (CB)

Istituto Comprensivo Scuola dell Infanzia, Primaria e Secondaria di I Grado 86048 Sant Elia a Pianisi (CB) Prot. N.3548 a/19 Atti Albo Pretorio Sito web PER I DOCENTI SCUOLA PRIMARIA (SECONDO BIENNIO) E SECONDARIA DI PRIMO GRADO Estratto da articolo di Cornoldi e al., 2010: Il primo strumento compensativo per

Dettagli

Metrika La formazione linguistica, una scelta di politica aziendale

Metrika La formazione linguistica, una scelta di politica aziendale Metrika La formazione linguistica, una scelta di politica aziendale Un importante tema dello sviluppo organizzativo è la valutazione della redditività degli investimenti. Quando si tratta, come per la

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

Gruppo per la Collaborazione tra Scuola e Famiglie GENITORI RAPPRESENTANTI NELLA SCUOLA Incontri formativi novembre 2013

Gruppo per la Collaborazione tra Scuola e Famiglie GENITORI RAPPRESENTANTI NELLA SCUOLA Incontri formativi novembre 2013 Gruppo per la Collaborazione tra Scuola e Famiglie GENITORI RAPPRESENTANTI NELLA SCUOLA Incontri formativi novembre 2013 Breve saluto con tre slides. Chi siamo: fondamentalmente siamo genitori per genitori

Dettagli

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo Progetto software 2008/2009 Docente Marianna Nicolosi Asmundo Obiettivi del corso Coinvolgervi nello sviluppo di un progetto software in cui mettere a frutto le conoscenze che avete acquisito durante i

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

SO Office Solutions SOLUZIONI E MACCHINE PER UFFICIO

SO Office Solutions SOLUZIONI E MACCHINE PER UFFICIO SO Office Solutions Con la Office Solutions da oggi. La realizzazione di qualsiasi progetto parte da un attenta analisi svolta con il Cliente per studiare insieme le esigenze al fine di individuare le

Dettagli

GIANLUIGI BALLARANI. I 10 Errori di Chi Non Riesce a Rendere Negli Esami Come Vorrebbe

GIANLUIGI BALLARANI. I 10 Errori di Chi Non Riesce a Rendere Negli Esami Come Vorrebbe GIANLUIGI BALLARANI I 10 Errori di Chi Non Riesce a Rendere Negli Esami Come Vorrebbe Individuarli e correggerli VOLUME 3 1 GIANLUIGI BALLARANI Autore di Esami No Problem Esami No Problem Tecniche per

Dettagli

Capitolo 20: Scelta Intertemporale

Capitolo 20: Scelta Intertemporale Capitolo 20: Scelta Intertemporale 20.1: Introduzione Gli elementi di teoria economica trattati finora possono essere applicati a vari contesti. Tra questi, due rivestono particolare importanza: la scelta

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 4 Marco Fusaro KPMG S.p.A. 1 CobiT Obiettivi del CobiT (Control Objectives

Dettagli

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES è una metodologia per implementare rapidamente sistemi informativi aziendali complessi,

Dettagli

E. Struttura e organizzazione del sistema

E. Struttura e organizzazione del sistema E. Struttura e organizzazione del sistema E. Struttura e organizzazione del sistema E.1 Sistema di gestione L azienda dovrebbe strutturare il SGSL seguendo i contenuti espressi nel presente documento,

Dettagli

Comma 2. Nel corso della riunione il datore di lavoro sottopone all esame dei partecipanti:

Comma 2. Nel corso della riunione il datore di lavoro sottopone all esame dei partecipanti: La riunione periodica D.Lgs. n. 81/2008 Articolo 18 Obblighi del datore di lavoro e del dirigente. Comma 1. Il datore di lavoro, che esercita le attività di cui all articolo 3, e i dirigenti, che organizzano

Dettagli

1. Calcolare la probabilità che estratte a caso ed assieme tre carte da un mazzo di 40, fra di esse vi sia un solo asso, di qualunque seme.

1. Calcolare la probabilità che estratte a caso ed assieme tre carte da un mazzo di 40, fra di esse vi sia un solo asso, di qualunque seme. Esercizi difficili sul calcolo delle probabilità. Calcolare la probabilità che estratte a caso ed assieme tre carte da un mazzo di, fra di esse vi sia un solo asso, di qualunque seme. Le parole a caso

Dettagli

1. Introduzione al corso

1. Introduzione al corso E107 WEB SYSTEM Corso on line di progettazione siti dinamici: livello base R E A L I Z Z A Z I O N E D I 1. Introduzione al corso By e107 Italian Team Sito web:http://www.e107italia.org Contatto: admin@e107italia.org

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 22 Sommario 1 Generalità

Dettagli

A cura di: Giangiacomo Freyrie

A cura di: Giangiacomo Freyrie 1 Buongiorno. La collaborazione con Federcongressi&eventi entra nel vivo e nella fase più operativa. Partiamo dal gruppo dei PCO. Il primo con cui siamo entrati in contatto e con cui abbiamo cominciato

Dettagli

LE RELAZIONI TRA RLS E RSPP: QUALI LE CRITICITA. Modalità corrette di approccio e di intervento da parte del RLS

LE RELAZIONI TRA RLS E RSPP: QUALI LE CRITICITA. Modalità corrette di approccio e di intervento da parte del RLS LE RELAZIONI TRA RLS E RSPP: QUALI LE CRITICITA Modalità corrette di approccio e di intervento da parte del RLS La mia relazione riprende il filo del discorso tracciato con la prima relazione che si soffermava

Dettagli

IL FAI DA TE NEL SOFTWARE DIDATTICO

IL FAI DA TE NEL SOFTWARE DIDATTICO IL FAI DA TE NEL SOFTWARE DIDATTICO La realizzazione delle tastiere virtuali didattiche - 3 a parte Prosegue l articolo in cui l autore chiarisce che l individuazione o l impostazione della struttura logica

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

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

Il recupero crediti nel franchising

Il recupero crediti nel franchising Il recupero crediti nel franchising I crediti insoluti rappresentano un grave problema per le imprese, soprattutto nell attuale periodo di crisi economica. Il settore del franchising non è certo immune

Dettagli

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali

Dettagli

Indagine su imprese e assicurazioni. Report dei risultati

Indagine su imprese e assicurazioni. Report dei risultati Indagine su imprese e assicurazioni Report dei risultati ITA045 Maggio 2012 Management summary_1 BACKGROUND E OBIETTIVI Il Giornale delle Assicurazioni, in occasione del convegno Assicurazioni e Sistema

Dettagli

1. LA MOTIVAZIONE. Imparare è una necessità umana

1. LA MOTIVAZIONE. Imparare è una necessità umana 1. LA MOTIVAZIONE Imparare è una necessità umana La parola studiare spesso ha un retrogusto amaro e richiama alla memoria lunghe ore passate a ripassare i vocaboli di latino o a fare dei calcoli dei quali

Dettagli

La Fantasia è più importante del sapere Vuoi migliorare il tuo business, migliora il tuo sito!

La Fantasia è più importante del sapere Vuoi migliorare il tuo business, migliora il tuo sito! Vuoi migliorare il tuo business, migliora il tuo sito! Migliora il tuo sito e migliorerai il tuo business Ti sei mai domandato se il tuo sito aziendale è professionale? È pronto a fare quello che ti aspetti

Dettagli

L essenziale da sapere per rendere usabile un sito web

L essenziale da sapere per rendere usabile un sito web L essenziale da sapere per rendere usabile un sito web I principi base dell usabilità 5 8 linee guida per scrivere per il web 7 10 linee guida per l e-commerce 10 Pagina 2 I PRINCIPI BASE DELL USABILITÀ

Dettagli

R. De Pari. CO0142 rev. B 1

R. De Pari. CO0142 rev. B 1 R. De Pari CO0142 rev. B 1 VERIFICA ISPETTIVA PER LA QUALITÀ (O AUDIT DELLA QUALITÀ) - DEFINIZIONE Processo sistematico, indipendente e documentato per ottenere evidenze della Verifica Ispettiva e valutarle

Dettagli

Le 5 cose da sapere prima di scegliere un preventivo per un nuovo sito web

Le 5 cose da sapere prima di scegliere un preventivo per un nuovo sito web Le 5 cose da sapere prima di scegliere un preventivo per un nuovo sito web Sono sempre di più i liberi professionisti e le imprese che vogliono avviare o espandere la propria attività e hanno compreso

Dettagli

PROGETTO DI FORMAZIONE SUL TEMA

PROGETTO DI FORMAZIONE SUL TEMA FIRENZE 1 PROGETTO DI FORMAZIONE SUL TEMA IL SISTEMA DI PROGRAMMAZIONE E CONTROLLO: RIFERIMENTI CONCETTUALI E NORMATIVI POSTI A CONFRONTO CON LA REALTÀ AZIENDALE FIRENZE 2 INDICE PREMESSA 3 MOTIVAZIONI

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

PMO: così fanno le grandi aziende

PMO: così fanno le grandi aziende PMO: così fanno le grandi aziende Tutte le grandi aziende hanno al loro interno un PMO - Project Management Office che si occupa di coordinare tutti i progetti e i programmi aziendali. In Italia il project

Dettagli

ORGANIZZAZIONE DEL PROGETTO

ORGANIZZAZIONE DEL PROGETTO ORGANIZZAZIONE DEL PROGETTO L organizzazione di un progetto è la realizzazione del processo di pianificazione. In altre parole, organizzare significa far funzionare le cose. Nello specifico, implica una

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

La difesa della proprietà intellettuale è una problematica molto importante per una serie di differenti elementi.

La difesa della proprietà intellettuale è una problematica molto importante per una serie di differenti elementi. La difesa della proprietà intellettuale è una problematica molto importante per una serie di differenti elementi. I fattori per i quali il tessile abbigliamento soffre di consistenti fenomeni di contraffazione,

Dettagli

RAPPORTO TRA L AGESCI E LE NORME RIGUARDANTI IL VOLONTARIATO E L ASSOCIAZIONISMO

RAPPORTO TRA L AGESCI E LE NORME RIGUARDANTI IL VOLONTARIATO E L ASSOCIAZIONISMO RAPPORTO TRA L AGESCI E LE NORME RIGUARDANTI IL VOLONTARIATO E L ASSOCIAZIONISMO 1. LA PREMESSA 2. LA DEFINIZIONE GIURIDICA 3. LA STORIA 4. I PUNTI DA PONDERARE 5. LA SITUAZIONE ATTUALE 6. CI FERMIAMO

Dettagli

ELEMENTI DI MISURAZIONE DELL EFFICACIA

ELEMENTI DI MISURAZIONE DELL EFFICACIA ELEMENTI DI MISURAZIONE DELL EFFICACIA La misurazione delle prestazioni (cd. performance) associate ad un qualsiasi processo o azione manageriale si può realizzare attraverso un sistema di indicatori predefiniti

Dettagli

GUIDA DI APPROFONDIMENTO LA GESTIONE DEI CLIENTI A CURA DEL BIC SARDEGNA SPA

GUIDA DI APPROFONDIMENTO LA GESTIONE DEI CLIENTI A CURA DEL BIC SARDEGNA SPA GUIDA DI APPROFONDIMENTO LA GESTIONE DEI CLIENTI A CURA DEL BIC SARDEGNA SPA 1 SOMMARIO PREMESSA... 3 ORIENTAMENTO ALLA SODDISFAZIONE DEL CLIENTE... 3 ASPETTATIVE E SODDISFAZIONE DEL CLIENTE... 3 MISURARE

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

Dettagli

Obiettivo Principale: Spiegare come la stessa cosa possa essere realizzata in molti modi diversi e come, a volte, ci siano modi migliori di altri.

Obiettivo Principale: Spiegare come la stessa cosa possa essere realizzata in molti modi diversi e come, a volte, ci siano modi migliori di altri. 6 LEZIONE: Algoritmi Tempo della lezione: 45-60 Minuti. Tempo di preparazione: 10-25 Minuti (a seconda che tu abbia dei Tangram disponibili o debba tagliarli a mano) Obiettivo Principale: Spiegare come

Dettagli

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione.

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. La Compagnia Della Rinascita PEOPLE CARE Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. PEOPLE CARE Un equipe di professionisti che si

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

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business 2 La guida CRM per eliminare le incertezze: prendete il controllo del vostro business (2 - migliorate la vostra credibilità: i 5 passi per dimostrare l efficacia del Marketing) Pagina 1 di 9 SOMMARIO PREMESSA...

Dettagli

Domanda e offerta di lavoro

Domanda e offerta di lavoro Domanda e offerta di lavoro 1. Assumere (e licenziare) lavoratori Anche la decisione di assumere o licenziare lavoratori dipende dai costi che si devono sostenere e dai ricavi che si possono ottenere.

Dettagli

Il Continuous Auditing come garanzia di successo dell IT Governance

Il Continuous Auditing come garanzia di successo dell IT Governance Il Continuous Auditing come garanzia di successo dell IT Governance Essere consapevoli del proprio livello di sicurezza per agire di conseguenza A cura di Alessandro Da Re CRISC, Partner & CEO a.dare@logicalsecurity.it

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Che fare quando un RLS vede una situazione di rischio o di disagio per i lavoratori?

Che fare quando un RLS vede una situazione di rischio o di disagio per i lavoratori? Le proposte emerse dai gruppi di RLS 1 Che fare quando un RLS vede una situazione di rischio o di disagio per i lavoratori? Il RLS consulta il documento di valutazione dei rischi e verifica se il rischio

Dettagli

Introduzione. Perché è stato scritto questo libro

Introduzione. Perché è stato scritto questo libro Introduzione Perché è stato scritto questo libro Sul mercato sono presenti molti libri introduttivi a Visual C# 2005, tuttavia l autore ha deciso di scrivere il presente volume perché è convinto che possa

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI 1. Lavorare per progetti La parola, oltre ad avere il significato del lessico comune, significa anche approccio manageriale, soprattutto da quando

Dettagli

Accogliere e trattenere i volontari in associazione. Daniela Caretto Lecce, 27-28 aprile

Accogliere e trattenere i volontari in associazione. Daniela Caretto Lecce, 27-28 aprile Accogliere e trattenere i volontari in associazione Daniela Caretto Lecce, 27-28 aprile Accoglienza Ogni volontario dovrebbe fin dal primo incontro con l associazione, potersi sentire accolto e a proprio

Dettagli

La risk analisys tra metodologie standard e tecniche proprietarie (ICT Security - giugno 2007)

La risk analisys tra metodologie standard e tecniche proprietarie (ICT Security - giugno 2007) La risk analisys tra metodologie standard e tecniche proprietarie (ICT Security - giugno 2007) Con questo articolo intendiamo porre a confronto seppure in maniera non esaustiva le tecniche di analisi dei

Dettagli

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI.

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI. CARTA DEI SERVIZI La qualità del servizio nei confronti dell Utente e la soddisfazione per l utilizzo delle soluzioni sono obiettivi strategici per Sistemi. Le soluzioni software Sistemi, siano esse installate

Dettagli

PREVEDERE LE VENDITE PER IL REVENUE MANAGEMENT

PREVEDERE LE VENDITE PER IL REVENUE MANAGEMENT Lezione n. 2 - PREVISIONE 1 PREVEDERE LE VENDITE PER IL REVENUE MANAGEMENT AUTORI Paolo Desinano Centro Italiano di Studi Superiori sul Turismo di Assisi Riccardo Di Prima Proxima Service INTRODUZIONE

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

Il Piano di comunicazione

Il Piano di comunicazione Il Piano di comunicazione 23 lezione 11 novembre 2011 Cosa è un piano di comunicazione Il piano di comunicazione è uno strumento utilizzato da un organizzazione per programmare le proprie azioni di comunicazione

Dettagli

L APPROCCIO POSITIVO DELLA PERSONA

L APPROCCIO POSITIVO DELLA PERSONA L APPROCCIO POSITIVO DELLA PERSONA di Andrea Canevaro L Approccio positivo 1 si fonda su 3 valori fondamentali: 1. Fiducia: credere nella persona che presenta un deficit e nelle sue possibilità. Per aiutare

Dettagli

La comunicazione per il successo nella vita e nel lavoro. Corso a cura di Agape Consulting

La comunicazione per il successo nella vita e nel lavoro. Corso a cura di Agape Consulting La comunicazione per il successo nella vita e nel lavoro Corso a cura di Agape Consulting La comunicazione per il successo nella vita e nel lavoro La capacità di comunicare e di negoziare è il principale

Dettagli

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio.

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio. Testo Esercizio Si consideri un sistema per la gestione di un magazzino di un negozio scelto a piacere dal candidato Il sistema è in grado di gestire le seguenti operazioni: Arrivo di nuovi prodotti; Controllo

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Il controllo di gestione nelle aziende che operano su commessa e l informativa di bilancio sui lavori in corso

Il controllo di gestione nelle aziende che operano su commessa e l informativa di bilancio sui lavori in corso Dipartimento Impresa Ambiente & Management Mirella Zito Il controllo di gestione nelle aziende che operano su commessa e l informativa di bilancio sui lavori in corso Copyright MMIX ARACNE editrice S.r.l.

Dettagli

Dopo la formazione i mentori saranno consapevoli che

Dopo la formazione i mentori saranno consapevoli che Modulo 2 Le tecniche del mentor/tutor 2.5. Perché e in che modo le competenze pedagogiche sono importanti per i mentori che lavorano nella formazione professionale (VET) Tempistica Tempo totale 2 ore:

Dettagli

IL MARKETING DELLA RISTORAZIONE. La promozione di un ristorante

IL MARKETING DELLA RISTORAZIONE. La promozione di un ristorante IL MARKETING DELLA RISTORAZIONE La promozione di un ristorante La promozione interna Si tratta delle strategie di vendita rivolte al cliente che è già «entrato» nel locale: Elaborazione di nuove proposte

Dettagli

Il marketing dei servizi. Il gap 1: non sapere cosa si aspettano i clienti

Il marketing dei servizi. Il gap 1: non sapere cosa si aspettano i clienti Il marketing dei servizi Il gap 1: non sapere cosa si aspettano i clienti Gap del fornitore n.1 gap di ascolto Per minimizzare il gap di ascolto è utile: Capire le aspettative dei clienti usando le ricerche

Dettagli

Applicazione pedagogica degli ambienti di apprendimento

Applicazione pedagogica degli ambienti di apprendimento Applicazione pedagogica degli ambienti di apprendimento Materiale pratico della durata di un ora circa Il nuovo ambiente di apprendimento rappresenterà un cambiamento pedagogico radicale o sarà soltanto

Dettagli

Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Articolazione Informatica

Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Articolazione Informatica Linee guida Secondo ciclo di istruzione Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Quadro orario generale 1 biennio 2 biennio 5 anno 1^ 2^ 3^ 4^ 5^ Sistemi e reti**

Dettagli

IDEE PER LO STUDIO DELLA MATEMATICA

IDEE PER LO STUDIO DELLA MATEMATICA IDEE PER LO STUDIO DELLA MATEMATICA A cura del 1 LA MATEMATICA: perché studiarla??? La matematica non è una disciplina fine a se stessa poichè fornisce strumenti importanti e utili in molti settori della

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Scegliere l abito. Laboratori gratuiti formativi ed informativi per la creazione d impresa 4 ORE

Scegliere l abito. Laboratori gratuiti formativi ed informativi per la creazione d impresa 4 ORE Scegliere l abito Distinguere le forme giuridiche per svolgere l attività imprenditoriale e individuare la forma più idonea in funzione dell idea d impresa Spesso le persone che intendono orientarsi all

Dettagli

METODOLOGIA DELLA VALUTAZIONE DEI DIPENDENTI

METODOLOGIA DELLA VALUTAZIONE DEI DIPENDENTI All. A METODOLOGIA DELLA VALUTAZIONE DEI DIPENDENTI ai sensi del vigente Contratto Collettivo Nazionale di Lavoro 26 SISTEMA DI VALUTAZIONE DEI DIPENDENTI AMBITO DI APPLICAZIONE: dipendenti CISSACA OBIETTIVO

Dettagli

Scopo della WBS. La regola del 100% Orientamento ai risultati

Scopo della WBS. La regola del 100% Orientamento ai risultati Le problematiche delle fasi del progetto CONCEZIONE ELABORAZIONE FINANZIAMENTO NEGOZIAZIONE ATTUAZIONE ATTUAZIONE - Definizione della successione delle attività esecutive - Allocare le risorse - Pianificare

Dettagli

GUIDA VELOCE PER TRAINER

GUIDA VELOCE PER TRAINER GUIDA VELOCE ~ 6 ~ GUIDA VELOCE PER TRAINER Perché usare il toolkit di EMPLOY? In quanto membro del personale docente, consulente di carriera, addetto al servizio per l impiego o chiunque interessato ad

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

ISTITUTO COMPRENSIVO ENEA TALPINO Nembro. Curricolo verticale IMPARARE AD IMPARARE

ISTITUTO COMPRENSIVO ENEA TALPINO Nembro. Curricolo verticale IMPARARE AD IMPARARE ISTITUTO COMPRENSIVO ENEA TALPINO Nembro Curricolo verticale IMPARARE AD IMPARARE 1 CURRICOLO INFANZIA-PRIMARIA-SECONDARIA DI I GRADO IMPARARE A IMPARARE Dal Curricolo Scuola Primaria e Secondaria di I

Dettagli

Italia: Imprese e Futuro Giugno 2010

Italia: Imprese e Futuro Giugno 2010 Giugno 2010 Premessa L obiettivo dell indagine è stato quello di registrare il sentire delle Aziende Italiane rispetto alla situazione economica attuale e soprattutto quali sono le aspettative per gli

Dettagli

Comunicazione di massa

Comunicazione di massa Persuadere per prevenire: tecniche di comunicazione nelle campagne di prevenzione. Fiorenzo Ranieri 1 Le campagne di prevenzione in Italia sono fortemente condizionate dalla impostazione legislativa. Le

Dettagli

LICEO CLASSICO C. CAVOUR DISCIPLINA : MATEMATICA PROGRAMMAZIONE DIDATTICA ED EDUCATIVA

LICEO CLASSICO C. CAVOUR DISCIPLINA : MATEMATICA PROGRAMMAZIONE DIDATTICA ED EDUCATIVA PROGRAMMAZIONE DIDATTICA ED EDUCATIVA 1. OBIETTIVI SPECIFICI DELLA DISCIPLINA PROGRAMMAZIONE PER COMPETENZE Le prime due/tre settimane sono state dedicate allo sviluppo di un modulo di allineamento per

Dettagli

BLUE Engineering Via Albenga 98 Rivoli (To) ITALY Danilo LAZZERI Amministratore Delegato Phone +39 011 9504211 Fax +39 011 9504216 info@blue-group.

BLUE Engineering Via Albenga 98 Rivoli (To) ITALY Danilo LAZZERI Amministratore Delegato Phone +39 011 9504211 Fax +39 011 9504216 info@blue-group. BLUE Engineering Via Albenga 98 Rivoli (To) ITALY Danilo LAZZERI Amministratore Delegato Phone +39 011 9504211 Fax +39 011 9504216 E-mail info@blue-group.it Il Cilea, l Engineering nel settore dell industria

Dettagli