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;

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

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

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

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

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

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

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

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

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

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

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

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 / 42 Sommario 1 Generalità

Dettagli

LE VENDITE COMPLESSE

LE VENDITE COMPLESSE LE VENDITE COMPLESSE 1 LE VENDITE COMPLESSE - PRINCIPI GENERALI Le vendite complesse differiscono da quelle semplici per molti importanti aspetti. Per avere successo è essenziale comprendere la psicologia

Dettagli

Progettazione per requisiti

Progettazione per requisiti Progettazione per requisiti White paper La riproduzione totale o parziale di questo documento è permessa solo se esplicitamente autorizzata da Lecit Consulting Copyright 2003 Lecit Consulting Sommario

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

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

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

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

The new outsourcing wave: multisourcing

The new outsourcing wave: multisourcing EVOLUZIONE DEI MODELLI DI OUTSOURCING La pratica dell outsourcing, cioè del trasferire all esterno dell azienda singole attività, processi o infrastrutture è in voga da tempo, e negli anni ha dimostrato

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

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

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

Dettagli

Stima delle Risorse di un Progetto

Stima delle Risorse di un Progetto Stima delle Risorse di un Progetto di Vito Madaio (Quali sono i benefici delle stime, i principali approcci e come utilizzarle nei progetti reali.) La stima delle esigenze di risorse di solito si effettua

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

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

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

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

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

Capitolo 33: Beni Pubblici

Capitolo 33: Beni Pubblici Capitolo 33: Beni Pubblici 33.1: Introduzione In questo capitolo discutiamo le problematiche connesse alla fornitura privata dei beni pubblici, concludendo per l opportunità dell intervento pubblico in

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

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

La progettazione del software nelle piccole o micro imprese

La progettazione del software nelle piccole o micro imprese La progettazione del software nelle piccole o micro imprese Il contenuto di questo documento è strettamente confidenziale, la visione dello stesso è consentita solo al personale di FadeOut Snc e della

Dettagli

«Sono delle teste dure!» ma è proprio vero?

«Sono delle teste dure!» ma è proprio vero? «Sono delle teste dure!» ma è proprio vero? Consigli per motivare al comportamento sicuro sul lavoro Forse vi è già capitato di trovarvi nei panni di questo allenatore di hockey e di pensare che i vostri

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

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 20 gennaio 2009 INDICE Sezione Contenuto 1. Il programma Responsible Care: scopo e campo di applicazione

Dettagli

I COMMENTI DI ISTITUTO AMBIENTE EUROPA AL D. Lgs. 81/08 ( TESTO UNICO ) 4 - FORMAZIONE DEI PREPOSTI: valutazioni e proposte

I COMMENTI DI ISTITUTO AMBIENTE EUROPA AL D. Lgs. 81/08 ( TESTO UNICO ) 4 - FORMAZIONE DEI PREPOSTI: valutazioni e proposte valutazioni e proposte FORMAZIONE DEI PREPOSTI: valutazioni e proposte di Attilio Pagano Psicologo del Lavoro e formatore 1. ANALISI CRITICA DELLE NORME Tra le principali innovazioni portate dal decreto

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

Criteri fondamentali per un sistema CRM

Criteri fondamentali per un sistema CRM Criteri fondamentali per un sistema CRM Definizione di C.R.M. - Customer Relationship Management Le aziende di maggiore successo dimostrano abilità nell identificare, capire e soddisfare i bisogni e le

Dettagli

Pensavamo fosse. invece..

Pensavamo fosse. invece.. Pensavamo fosse. invece.. La presentazione che segue racconta il percorso scolastico di uno studente straniero con una lunga serie di bocciature alle spalle. Istituto Comprensivo Darfo2 La storia O. è

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

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

Psicologa, Psicoterapeuta, Antropologa Articolo scaricato da HT Psicologia PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI

Psicologa, Psicoterapeuta, Antropologa Articolo scaricato da HT Psicologia PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI Project management Pag. 1 di 5 PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI I motivi per cui la metodologia di project management è attualmente ritenuta uno strumento vincente nella

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

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

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

CATALOGO FORMATIVO KNOWITA

CATALOGO FORMATIVO KNOWITA Il Catalogo Formativo 2015 di Knowità è composto da incontri pensati per soddisfare le esigenze di figure di responsabilità che necessitano di risposte concrete alle principali e più attuali priorità aziendali.

Dettagli

Introduzione all analisi per flussi

Introduzione all analisi per flussi C 1 a p i t o l o Introduzione all analisi per flussi 1 I flussi finanziari L obiettivo di questo libro è illustrare una diversa visione d impresa: non più quella statica legata alla contabilità e all

Dettagli

CAMERA DI COMMERCIO DI TORINO

CAMERA DI COMMERCIO DI TORINO Definizioni e concetti generali 1.1 Che cos'è il business plan? Il business plan è un documento che riassume ed espone la rappresentazione dinamica e prevista dello sviluppo di un piano d impresa. Il business

Dettagli

IL CERVELLO QUESTO SCONOSCIUTO

IL CERVELLO QUESTO SCONOSCIUTO 1 IL CERVELLO QUESTO SCONOSCIUTO Nonostante il progresso della conoscenza e delle tecnologie sappiamo ancora molto poco sul funzionamento del nostro cervello e sulle sue possibilità tanto che, fra gli

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

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

LINGUE E LETTERATURE STRANIERE. Inglese, francese, tedesco, spagnolo

LINGUE E LETTERATURE STRANIERE. Inglese, francese, tedesco, spagnolo LINGUE E LETTERATURE STRANIERE Inglese, francese, tedesco, spagnolo Indirizzi Classico e Linguistico BIENNIO (Li, L2), (L3 l a e 2 a liceo) OBIETTIVI GENERALI (L1, L2, L3 e sezioni classiche) Obiettivo

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

Gestione del rischio operativo

Gestione del rischio operativo Comitato di Basilea per la vigilanza bancaria Gestione del rischio operativo Il Comitato di Basilea per la vigilanza bancaria ha avviato di recente un programma di lavoro sul rischio operativo. Il controllo

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

8 Il futuro dei futures

8 Il futuro dei futures Introduzione Come accade spesso negli ultimi tempi, il titolo di questo libro è volutamente ambiguo, ma in questo caso non si tratta solo di un espediente retorico: come spero si colga nel corso della

Dettagli

Programmazione didattica per Matematica. Primo Biennio. a.s. 2014-2015

Programmazione didattica per Matematica. Primo Biennio. a.s. 2014-2015 Programmazione didattica per Matematica Primo Biennio a.s. 2014-2015 Obiettivi educativi e didattici. Lo studio della matematica, secondo le indicazioni nazionali, concorre con le altre discipline, alla

Dettagli

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE ottobre 2010 SCOPO E CAMPO DI APPLICAZIONE Scopo delle

Dettagli

Il Quotidiano in Classe. Classe III sez. B

Il Quotidiano in Classe. Classe III sez. B Il Quotidiano in Classe Classe III sez. B Report degli articoli pubblicati Dagli studenti sul HYPERLINK "iloquotidiano.it" Ilquotidianoinclasse.it Allestimento di Lorenzo Testa Supervisione di Chiara Marra

Dettagli

Introduzione. Capitolo 1

Introduzione. Capitolo 1 Capitolo 1 Introduzione Che cos è un azienda lean? Sono molte, al giorno d oggi, le imprese che stanno trasformandosi in azienda lean, convertendo i loro sistemi di produzione di massa ormai obsoleti in

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

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

Dirigere Aziende di Successo

Dirigere Aziende di Successo Piano di Formazione Dirigere Aziende di Successo Progetto Finanziato dal Fondo Coordinato da e Informazioni: Per causare cambiamenti in azienda è necessario essere "allenati" nel dettaglio allo scopo di

Dettagli

La valutazione del personale. Come la tecnologia può supportare i processi HR

La valutazione del personale. Come la tecnologia può supportare i processi HR La valutazione del personale Come la tecnologia può supportare i processi HR Introduzione Il tema della valutazione del personale diventa semprè più la priorità nella gestione del proprio business. Con

Dettagli

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

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

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

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

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

Contributo alla discussione su La rappresentazione del rischio nella stima della pensione complementare

Contributo alla discussione su La rappresentazione del rischio nella stima della pensione complementare Roma, 15/07/2013 Contributo alla discussione su La rappresentazione del rischio nella stima della pensione complementare Mefop Tel: 06 48073531 Fax: 06 48073548 E-mail: mefop@mefop.it Capitale sociale

Dettagli

GUIDA AL BUSINESS PLAN*

GUIDA AL BUSINESS PLAN* GUIDA AL BUSINESS PLAN* *La guida può essere utilizzata dai partecipanti al Concorso che non richiedono assistenza per la compilazione del businnes plan INDICE Introduzione 1. Quando e perché un business

Dettagli

INDICE. 1.Perché fare Qualità. 2. Qualità e non-qualità. 3. Le potenzialità del Sistema di gestione. 4. La ISO 9001:2015

INDICE. 1.Perché fare Qualità. 2. Qualità e non-qualità. 3. Le potenzialità del Sistema di gestione. 4. La ISO 9001:2015 LE NOVITA INDICE 1.Perché fare Qualità 2. Qualità e non-qualità 3. Le potenzialità del Sistema di gestione 4. La ISO 9001:2015 1. PERCHE FARE QUALITA Obiettivo di ogni azienda è aumentare la produttività,

Dettagli

Perché affidarsi a tecnico di proget

Perché affidarsi a tecnico di proget TEC. Baroni 45 imp 2-04-2004 10:54 Pagina 50 TECNICA Perché affidarsi a tecnico di proget d i S a r a B a r o n i Uno studio di ingegneria, maturando esperienza in realtà differenti, sviluppa una competenza

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

La validazione del progetto alle imprese : il rimedio giusto per eliminare l errore progettuale come causa del contenzioso

La validazione del progetto alle imprese : il rimedio giusto per eliminare l errore progettuale come causa del contenzioso Dott. Ing. Donato Carlea Direttore Generale Servizio Ispettivo Autorità di Vigilanza Contratti pubblici Professore Straordinario Facoltà Ingegneria Univ. Perugia - Facoltà Architettura Univ. La Sapienza

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

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita.

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita. IL CRM NELL ERA DEL CLIENTE modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita ebook 1 SOMMARIO Introduzione Allineare meglio le vendite e il marketing Creare

Dettagli

ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA SCUOLA DI LETTERE E BENI CULTURALI. Corso di laurea magistrale in

ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA SCUOLA DI LETTERE E BENI CULTURALI. Corso di laurea magistrale in ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA SCUOLA DI LETTERE E BENI CULTURALI Corso di laurea magistrale in Scienze della Comunicazione Pubblica e Sociale HR E Marketing. Analisi Dello Sviluppo Marketing

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

LA PROFESSIONE DEL WEB DESIGNER

LA PROFESSIONE DEL WEB DESIGNER LA PROFESSIONE DEL WEB DESIGNER Lezione 1 1 Web Design Lafiguracentralenelprogettodiunsitowebèilwebdesigner:eglisioccupadell'aspetto visivo e del coinvolgimento emotivo di siti Web business to business

Dettagli

Laboratorio di Didattica dell Analisi Prof. F. Spagnolo. Il problema dell inversione: dal grafico all espressione analitica di una funzione

Laboratorio di Didattica dell Analisi Prof. F. Spagnolo. Il problema dell inversione: dal grafico all espressione analitica di una funzione S.I.S.S.I.S. - Indirizzo 2 Laboratorio di Didattica dell Analisi Prof. F. Spagnolo Il problema dell inversione: dal grafico all espressione analitica di una funzione Erasmo Modica erasmo@galois.it Giovanna

Dettagli

Possiamo calcolare facilmente il valore attuale del bond A e del bond B come segue: VA A = 925.93 = 1000/1.08 VA B = 826.45 = 1000/(1.

Possiamo calcolare facilmente il valore attuale del bond A e del bond B come segue: VA A = 925.93 = 1000/1.08 VA B = 826.45 = 1000/(1. Appendice 5A La struttura temporale dei tassi di interesse, dei tassi spot e del rendimento alla scadenza Nel capitolo 5 abbiamo ipotizzato che il tasso di interesse rimanga costante per tutti i periodi

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

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

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

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

Fino a pochi anni fa chi voleva approfondire la valutazione di un. prodotto si riferiva spesso all esperienza diretta di parenti, amici e

Fino a pochi anni fa chi voleva approfondire la valutazione di un. prodotto si riferiva spesso all esperienza diretta di parenti, amici e 1 Scopo della guida Fino a pochi anni fa chi voleva approfondire la valutazione di un prodotto si riferiva spesso all esperienza diretta di parenti, amici e conoscenti che lo avessero già sperimentato,

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

ARIES. Architettura per l implementazione rapida dei sistemi aziendali

ARIES. Architettura per l implementazione rapida dei sistemi aziendali ARIES Architettura per l implementazione rapida dei sistemi aziendali P r e s e n ta z i o n e d e l l a m e t o d o l o g i a a r i e s ARIES è una metodologia che consente di implementare rapidamente

Dettagli

IL SIGNIFICATO DEI COMPITI A CASA: oltre la necessità di apprendimento

IL SIGNIFICATO DEI COMPITI A CASA: oltre la necessità di apprendimento IL SIGNIFICATO DEI COMPITI A CASA: oltre la necessità di apprendimento Riflessioni su tempo, sviluppo, regole, autonomia, fiducia, sostegno Dr.ssa Nadia Badioli IL SENSO DEI COMPITI STRUMENTO PER: incentivare

Dettagli

Definizione dei requisiti

Definizione dei requisiti UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II FACOLTÀ DI SOCIOLOGIA - CORSO DI LAUREA IN CULTURE DIGITALI E DELLA COMUNICAZIONE Definizione dei requisiti Un modello di riferimento per la progettazione e

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 10/10/05 STATISTICA Antigone Marino La costruzione del questionario Il questionario di indagine è lo strumento di misura

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

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione Obiettivo della lezione Casi d uso La modellazione dei requisiti funzionali I casi d uso Gli attori Gli scenari Come scrivere casi d uso Casi d uso (use cases) Scenari d interazione Proposti da Ivar Jacobson

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE II ORGANIZZAZIONE DEL PROGETTO UDA 4 IL TEAM DI PROGETTO LEZIONE: IL

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

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli