Ingegneria del software versione 1.0.5

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Ingegneria del software versione 1.0.5"

Transcript

1 Ingegneria del software versione Appunti 19 luglio 2006 Indice 1 Ciclo di vita del software Processo di sviluppo del software Modelli Agile Dierenze con altri modelli Quando usarlo Iterativo - Incrementale RAD Vantaggi Svantaggi Extreme Programming Planning Game Small Relesases Customers on-site Test First Refactoring Simplicity System Metaphor Pair Programming Collective Code Ownership Continous Integration Standards Overtime: 40 hour week JUnit RUP RUP best practices Ciclo di vita del Progetto Il modello a Cascata - WaterFall Il modello a Spirale Il modello a Release UXF 13 3 Metriche codice sorgente LOC eloc lloc DLOC SLOC Vantaggi Svantaggi UMM 15 5 XMI 15 6 COTS 16 7 SCM Goal FPA 17 9 COCOMO Basic COCOMO COCOMO II CORBA DFD Linguaggio Z Esempio - Denizione sistema Esempio - Add

2 2 Indice 14 Diagrammi UML Diagramma casi d'uso Diagramma delle classi Diagramma delle sequenze Diagramma delle collaborazioni Diagramma di stato Diagramma delle attività Diagramma dei componenti Diagramma di distribuzione dei componenti (deployment) 24 Bibliograa 25

3 1 Ciclo di vita del software 3 1 Ciclo di vita del software L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato nale è il prodotto stesso e tutta la documentazione a esso associato[1]. Esistono varie fasi: 1. Analisi: ovvero l'indagine preliminare sul contesto in cui il prodotto software deve inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase può essere scomposta in sottoattività quali: (a) analisi di fattibilità, (b) analisi e modellazione del dominio applicativo, (c) analisi dei requisiti. 2. Progetto: in cui si deniscono le linee essenziali della struttura del sistema da realizzare, in funzione dei requisiti evidenziati dall'analisi e dal documento nale da essa creato. Anche questa fase può essere scomposta in sottoattività: (a) progetto architetturale, (b) al progetto dettagliato. In questa fase verrà sviluppando un documento che permetterà di avere una denizione della struttura di massima (architettura di alto livello) e una denizione delle caratteristiche dei singoli componenti (moduli) 3. Implementazione 4. Testing (a) testing dei singoli moduli, (b) testing del sistema integrato, (c) test funzionali, (d) test di performance, (e) test di accettazione, (f) test d'installazione. 5. Manutenzione

4 4 1 Ciclo di vita del software 1.1 Processo di sviluppo del software L'UML (Unied Modelling Language), ad esempio, è un linguaggio di modellazione, utilizzato dai processi per realizzare, organizzare, documentare i prodotti realizzati dalle fasi di cui il processo si compone. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare. Adottano un processo [1]. Il ciclo di sviluppo del software, nella maggior parte dei casi, è iterativo, e ogni iterazione produce una sua release. Elenchiamo di seguito le fasi principali che possono far parte di ogni singola iterazione: 1. Specica dei requisiti: ciò che viene richiesto dal committente 2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare il sistema (punto di vista logico) e per design lo studio di come il sistema deve venire implementato (punto di vista tecnico). Negli ultimi anni, la distinzione tradizionale tra analisi e design è entrata in crisi. 3. Implementazione 4. Integrazione e test 1.2 Modelli Esistono molti modelli per lo sviluppo del software: iterativo ( ), Waterfall (a cascata) (1970), RAD ( ), spirale (1985), RUP (1998), Extreme Programming (XP) (1999). Agile (2001),

5 1 Ciclo di vita del software Agile Agile è una metodologia di sviluppo del software, un framework. Ci sono più tipi di agile software per sviluppare questo metodo, questi possono essere trovati nell'organizzazione no-prot The Agile Alliance. Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole timeboxes, chiamate iterazioni, da una a quattro settimane. Ogni iterazione include delle fasi: planning, requirements analysis, design, coding, testing e documentation. Mentre una iterazione non garantisce il rilascio di un prodotto, l'agile software project, si propone di riuscire a rilasciare un nuovo software ad ogni iterazione. Alla ne di ogni iterazione, il tema ssa le priorità del progetto Dierenze con altri modelli <Agile> <Iterative> <Waterfall> <-*-**> Adaptive...Predictive Adaptive methods: si concentra sull'adattarsi velocemente ai cambiamenti. Predictive methods: si concentra sulla pianicazione dettagliata e futura del progetto Quando usarlo Più di 20 sviluppatori, distanza tra glil sviluppatori, mission- and life-critical eorts, command-and-control company cultures. 1.4 Iterativo - Incrementale Il modello iterativo, e incrementale, risponde alle debolezze dei modelli watefall. I due modelli di sviluppo iterativo più conosciuti sono RUP (Rational Unied Process), e DSDM (Dynamic Systems Development Method). Questo modello è una parte essenziale dell'xp (Extreme Programming) e tutti gli altri agile software frameworks.

6 6 1 Ciclo di vita del software 1.5 RAD (Rapid Application Development) RAD nato come risposta al metodologia non-agile, come il modello waterfall. Il problema con i precedenti modelli era quello che i requisiti cambiassero prima della conclusione del progetto, con il risultato di creare sistemi non utilizzabili Vantaggi Svantaggi accresce la velocità e qualità di sviluppo Questa velocità è dovuta all'uso di tool quali CASE 1 Per qualità nel modello RAD si intende il grado con il quale l'applicazione nita si riscontra con le aspettative del cliente, ed i costi di manutenzione bassi. Come svantaggi, riduce la scalabilità e le features. La scalabilità è ridotta perché questo modello parte da un prototipo e si evolve no alla applicazione nita; mentre riduce le features questo è dovuto al time boxing, le features vengono inserite tardi nelle versioni nali della release. 1.6 Extreme Programming L'extreme programming XP, è un modo di programmare che segue determinate regole, per cercare di ottimizzare il più possibile lavoro fatto dai programmatori [2]. Alcune di queste regole sono di seguito riportate: 1. Planning Game 2. Small Releases (Piccole release) 3. Customers on-site (Cliente sul posto) 4. Test First 5. Refactorig 6. Simplicity 7. System Metaphor 8. Pair Programming 9. Collective Code Ownership 10. Continous Integration 11. Code Standards 12. Overtime: 40 hour week L'obiettivo di questo tool è quello di catturare i requisiti e descriverli come codice nel modo più veloce possibile.

7 1 Ciclo di vita del software Planning Game Come Pianicare: Creare delle priorità (con il cliente) Stimare la dicoltà dei lavori (Lo sviluppatore) Lavorare in task paralleli, si è più veloci (Lo sviluppatore) Pianicare insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente) Small Relesases Signica piccole release frequenti, in genere prima dell'xp, si faceva il software per intero e poi si dava al committente validato; mentre ora si cerca di dare subito qualcosa al cliente, in modo che capisca subito se il software è corretto secondo le sue speciche; questo evita di fare lavoro inutile. In genere per il cliente viene sviluppato subito il 10% del programma in modo tale che sia veloce il riscontro in caso di problemi. Questa tecnica, evita la nascita e la morte poi di determinati software, con la perdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori 2 o difetti 3 nei software prodotti Customers on-site Il committente deve essere tenuto sempre in stretto contatto con gli sviluppatori. In genere succede che dopo aver ottenuto l'ordine di progettare un software, il programmatore ed il cliente non si sentono quasi più no a software terminato: questo non deve succedere. Con l'xp, lo sviluppatore chiede subito al committente cosa sono le sue priorità, i moduli che devono essere sviluppati prima, e come devono essere sviluppati. Coinvolgere il cliente nei test per sapere se il software per lui è corretto, mostrare se il programma per lui è user-friendly Test First In genere i test vengono eseguiti dopo lo sviluppo della applicazione. Mentre in XP, il development è guidato dai test, questa può sembrare una perdita di 2 Per errore si intende una dimenticanza del programmatore Es.: un errore di battitura... 3 Per difetto si intende un problema nei risultati ottenuti dal software, risultati inattesi. (Altrimenti detto bug, Fault.)

8 8 1 Ciclo di vita del software tempo ma poi alla ne: si ha si, una perdita di tempo iniziale, ma si recupera sulla ne del progetto; mentre con l'approccio tradizionale si ha una velocità maggiore all'inizio per poi decelerare alla ne nella fase di Testing Refactoring Con questo termine, si intende modicare il codice, modicarne la struttura, il usso di controllo ma non il risultato. Ad esempio rinominare un metodo, aggiungere metodi a delle classi(ma senza cambiare il risultato del modulo). Il refactoring serve in generale per migliorare la qualità del codice. Divisione di un grande metodo in più parti Simplicity Cercare di tenere il progetto più semplice possibile System Metaphor Usare metafore vicine al dominio del committente. Se il cliente è un produttore di automobili, cercare di parlare dello sviluppo del software in termini di produzione di automobili, questo è una forma per cercare di capire nel miglior cosa deve fare il software prodotto Pair Programming Con il termine pair programming si intende, la programmazione in gruppo, per esempio in due, questa viene richiesta quando il compito è particolarmente dicile; su lavori critici si lavora insieme Collective Code Ownership Il codice scritto è di tutti gli sviluppatori; se si trova un errore nel programma la colpa è dell'intero team. Bisogna dire che essendo il codice di tutti, chi vuole può fare tutte le modiche, se secondo lui un modulo non è corretto lo può modicare, a patto che usi i CVS (Concurrent Version System,controllo di versione); inoltre al termine della modica il modulo modicato devo dare lo stesso risultato nei test del modulo vecchio; in altre parole non devo alterare i risultati che il modulo vecchio dava. Se non è così, allora in quel caso, la colpa è del programmatore che ha svolto la modica, il quale non si è preoccupato di vedere se i test erano ancora corretti; in conclusione, più libertà ma anche più responsabilità.

9 1 Ciclo di vita del software Continous Integration In genere il test di integrità viene fatto alla ne dello sviluppo dei singoli moduli con una frequenza molto alta di errori. L'XP dice che questo test deve essere fatto in modo più frequente proprio per evitare problemi di integrazione alla ne del progetto, molto più dicili da trovare e sistemare Standards Cercare di scrivere codice il più possibile in modo standard: es in java, i nomi delle classi iniziano con la lettera maiuscola, mentre per i nomi dei metodi si usano dei verbi Overtime: 40 hour week Per uno sviluppatore, le ore di straordinario, (overtime), sono permesse solo per una settimana, altrimenti c'è il rischio di commettere errori, mentre l'orario lavorativo normale non deve superare le 40 ore settimanali JUnit E' uno strumento che serve per eseguire Test di unità in Java. Utilizza la libreria Java riessione (per gestire le classi). Terminologia: Unit Test: una classe che testa un'altra classe Caso di Test: chiama un metodo con un input particolare e si osserva se il risultato è corretto Test Suite: una serie di casi di test Test Runner: serve per far partire i test Junit, introduce una nuova classe: nomeclassetest. Inoltre introduce due classi con nomi ssi: setup: inizializza la classe per eseguire i test teardown: libera la classe Junit utilizza le asserzioni per produrre il risultato dei test e vedere se sono corretti. Esempio in Java1:

10 10 1 Ciclo di vita del software 1 public class ES { 3 int mcd ( int x, int y) { 5... } 7 } 9 /* C r e o un ' a l t r a c l a s s e */ 11 public class ES TEST { 13 void testmcd () { 15 mcd (10,2) ; // Mi a s p e t t o c h e r e s t i t u i s c a 2 } 17 asserttrue ( mcd (10,2) ==2) ; asserttrue ( mcd (6,12) ==6) ; 19 } 21 /* * * * T i p i di A s s e r z i o n i * * * */ 23 static void asserttrue ( boolean test ) static void asserttrue ( String message, boolean test ) 25 static void assertfalse ( boolean test ) 27 static void assertfalse ( String message, boolean test ) 29 static void assertequals ( expected, actual ) static void assertequals ( String message, expected, actual ) Codice 1: Esempio in pseudolinguaggio Java Limiti e problemi del Testing con JUnit È una buona idea scrivere metodi che controllano lo stato di un oggetto Non è facile testare il codice delle GUI Con questo metodo si controlla l'output ma ha volte non è facile scrivere codice per questo controllo Non è facile testare svariati metodi che lavorano in parallelo per dare un risultato

11 1 Ciclo di vita del software 11 Sono comunque state proposte possibili soluzioni 1.7 RUP RUP (Rational Unied Process) è un software molto noto di sviluppo iterativo. RUP deve essere visto non come attraverso una singola prospettiva di lavoro, ma piuttosto un framework operativo adattabile alle esigenze RUP best practices 1. Sviluppo del software in modo iterativo, 2. gestione dei requisiti, 3. verica della qualità del codice, 4. CVS controllo dei cambiamenti apportati al software. RUP usa il modello iterativo per le seguenti ragioni: Il processo di integrazione viene fatto passo dopo passo durante lo sviluppo del software, limitandosi a farlo per pochi elementi alla volta, l'implementazione viene fatta per moduli, facilitando il riuso del software, se i requisiti cambiano è possibile adattarsi, l'architettura del software viene migliorata ad ogni release Ciclo di vita del Progetto È formato da quattro fasi vedi Figura 1 a Pagina 12: 1. Inception Phase (a) Stakeholder denizione, stima dei costi, tempi, (b) comprensione dei requisiti, (c) priorità costi/tempi, rischio, sviluppo del processo, (d) studio del prototipo architetturale che si è studiato, (e) spese attuali vs spese pianicate. 2. Elaboration Phase

12 12 1 Ciclo di vita del software (a) Generazione casi d'uso i casi d'uso completati all'80% (b) descrizione dell'architettura software, (c) piano di sviluppo per coprire tutto il progetto. 3. Construction Phase, 4. Transition Phase. Figura 1: Ciclo di vita del progetto Il modello a Cascata - WaterFall Figura 2: Modello WaterFall L'output di ogni fase è l'input della successiva; il principale limite di questo modello, è il fatto di non poter tornare indietro; se c'è un problema nel software che viene scoperto tardi bisogna ricominciare Il modello a Spirale In questo modello vedi Figura 3 a pagina 13, si crea un prototipo, attraverso le varie fasi: analisi dei requisiti, specica... e poi si fa l'analisi dei rischi

13 2 UXF 13 Figura 3: Modello a Spirale anche con il cliente per vedere se si può proseguire. Il principale vantaggio dei modelli a spirale e Release e che il software è in continua evoluzione [3] Il modello a Release In questo modello, si crea una prima release da sottoporre al cliente per ottenere un primo feedback; per poi correggerla o svilupparla ancora. Alla ne di tutte le release si ottiene il prodotto nale. 2 UXF UXF (UML exchange Format) è un modello di interscambio di formati per UML(Unied Modeling Language) basato su XML. Permette una alta inter operabilità; il team che sviluppa codice tramite questo modello, può riutilizzare e scambiare le informazioni tramite lo standard XML. XML è un sosticato sottoinsieme dell'sgml (Standard Generalized Markup Language: ISO 8879) i principali vantaggi sono: Indipendenza dal vendor (vender independence), Estensibilità, Possibilità di rappresentare delle informazioni complesse,

14 14 3 Metriche codice sorgente Leggibilità umana (Human readability), Interoperabilità tra i tools di sviluppo. 3 Metriche codice sorgente 3.1 LOC Line of code (LOC). LOC sono usate per stimare i tempi ed i costi. 3.2 eloc Eective line of code (ELOC), è la misura di tutte le line di codice che non sono commenti, spazi bianchi, e parentesi. Questa metrica rappresenta la quantità del lavoro. 3.3 lloc Logical lines of code (ILOC) rappresenta una metrica per gli statements; es.: for. Esempio: Source code line LOC eloc lloc Comment Blank if (x<10) // test range x x x { x // update y coordinate x x y = x + 1; x x x } x DLOC Developed line of code (DLOC). Include tutto il programma ed gli statement. Esiste anche il Kilo line of code (KLOC). 3.5 SLOC SLOC (Source lines of code) è una metrica usata per misurare il codice di un certo programma. SLOC viene usato per stimare lo sforzo richiesto per sviluppare un certo software.

15 5 XMI Vantaggi Automatizzare il conteggi delle linee di codice tramite tools Una metrica intuitiva: le righe di un software possono essere visionate Svantaggi 1. Non si può quanticare il costo, di un software contando le linee di codice, in altre parole contando solo la fase di codica la quale occupa solo il 33% - 35% di tutti il processo, 2. non ci permette di catturare questa diversità: un programmatore può scrivere poche righe di codice ma molto signicative, mentre un secondo programmatore ne scrive molte ma meno signicative e con più errori, 3. linguaggi dierenti, 4. GUI, tramite queste interfacce, il programmatore può fare copia ed incolla del codice già scritto in precedenza. 4 UMM UMM (UN/CEFACT's 4 Modeling Methodology), è una metodologia di modellazione la quale si sviluppa tramite UN/CEFACT. 5 XMI XMI (XML Metadata Interchange) è uno standard OMG per lo scambio di metadati tramite il linguaggio XML. Può essere usato per qualsiasi metadato purché questo possa essere espresso tramite MOF (Meta-Object Facility). L'uso più comune di XMI è per l'interscambio di modelli UML, i quali possono essere usati anche per altri linguaggi. XML - extensible Markup Language, W3C standard. UML - Unied Modeling Language, OMG modeling standard. 4 (The United Nations Centre for Trade facilitation and Electronic Business) UN/CE- FACT ha come scopo migliorare il business, e l'organizzazione amministrativa, sviluppo e transazioni economiche, scambio di prodotti e servizi; contribuisce allo sviluppo del commercio globale.

16 16 7 SCM MOF - Meta Object Facility, OMG DSL per la specica di metamodelli. MOF Mapping a XMI 6 COTS (Commercial o-the-shelf); COTS è un termine applicato nell'ambito sia dei prodotti software che hardware, il quale dice quando questo prodotto è pronto e disponibile alla vendita al pubblico. GOTS: government o-the-shelf, MOTS: modiable o-the-shelf, oppure military o-the-shelf. La motivazione che spinge ad utilizzare dei componenti COTS, è che riduce il tempo ed i costi di sviluppo del software; perché i componenti possono comprati e non progettati da zero. A volte tuttavia i costi di integrazione e la dipendenza da terze parti possono accrescere i costi. 7 SCM SCM (Software Conguration Management) è una parte del CM (Conguration Management). Risponde a queste domande: 1. Qualcuno fa qualcosa, come possiamo riprodurla? Spesso il problema si evolve e non è possibile riprodurlo in modo identico, ma servono dei cambiamenti incrementali. Tradizionalmente CM si è concentrato sul controllo e la creazione di prodotti semplici. Ai nostri giorni, la sda è quella fare il minor numero di incrementi; valutando la complessità del sistema che si sta sviluppando. 7.1 Goal Conguration Identication- Con quale codice noi lavoriamo? Conguration Control- Controllo delle release e eventuali cambiamenti. Status Accounting- Registrazione e report dei componenti.

17 8 FPA 17 Review- Assicurarsi della completezza dei vari componenti. Build Management- Gestione dei processi e dei tool utilizzati nel progetto FPA FPA (Function Point Analysis) è un metodo che misura la dimensione funzionale di un sistema informativo. Questo viene fatto osservando le transazioni funzionali e logiche del les rilevanti per gli utenti nel loro business [5]. Necessità di alcuni passi: 1. Identicare le funzioni del sistema che sono rilevanti per gli utenti 2. Determinare la complessità di ogni funzione 3. Contare le funzioni di tipo di dati per determinare il loro contributi al numero dei function point non pesati 4. Contare le funzioni di tipo transazionale per determinare il loro contributi al numero dei function point non pesati 5. Determinare il fattore di aggiustamento del valore 6. Calcolare il numero di function point pesati. Step 1 - FPA distingue tra cinque tipi di funzioni utente: 1. Internal Logical File (ILF) 2. External Interface File (EIF) 3. External Input (EI) 4. External Output (EO) 5. External Inquiry (EQ) Step 2 - FPA distingue tra tre tipi di complessità: 1. Low 2. Average 3. High

18 18 9 COCOMO 9 COCOMO COCOMO (COnstructive COst MOdel) è un modello progettato da Barry Boehm, per dare una stima del numero di uomini-mese che prenderanno parte allo sviluppo di un software. COCOMO consiste in una gerarchia di tre crescenti livelli di dettaglio: 1. Basic COCOMO: è statico, sforzo e costo dello sviluppo di un software come funzione della dimensione di un programma espressa nella sua stima delle linee di codice. 2. Intermediate COCOMO: sforzo come funzione della dimensione del programma e i cost drivers che includono subjective assessment of product, hardware, personale e project attributes. 3. Detailed COCOMO: incorpora tutte le caratteristiche della versione intermedia con un impatto dei cost driver ad ogni passo (analisi, progetto, codica... ), del processo di produzione del software. 9.1 Basic COCOMO Può essere applicato a tre tipologie di progetto: 1. Organic projects: sono relativamente piccoli, semplici progetti, 2. Semi-detached projects: sono una via di mezzo in termini di dimensione e complessità, 3. Embedded projects: sono progetti che devono essere sviluppati con hardware, software. L'equazione del basic COCOMO: E = a b (KLOC) b b D = c b (E) d b P = E/D dove E è lo sforzo (persone-mese), D è il tempo di sviluppo in un mese, KLOC è la stima del numero di line di codice per i progetto (espresse in migliaia), P è il numero di persone richieste. I coecienti a b, b b, c b, d b sono dati Tabella 1 a Pagina 19.

19 10 COCOMO II COCOMO II Software Project a b b b c b d b Organic Semi-detached Embedded Tabella 1: Coecienti Basic COCOMO Nel COCOMO II vengono apportate modiche al COCOMO I. Vengono deniti tre livelli di COCOMO, che corrispondono a tre classi di applicazioni e utilizzano informazioni reperibili in tre diversi momenti del ciclo di vita: 1. Application Composition: è il settore di chi utilizza primitive di alto livello per programmare (ad esempio GUI, spreadsheet) o si riferisce alla fase in cui viene generalmente eettuata una prototipazione per risolvere problemi ad alto rischio (interfacce utente, interazione software/sistema, prestazioni, maturità della tecnologia); vengono utilizzati gli Object Points, in quanto si ritiene che siano disponibili in maniera adabile in questa fase 2. Early Design: si passa alla fase di progetto, con l'esplorazione di alternative per le architetture; vengono usati i Function Points, il linguaggio e alcuni driver di costo in numero limitato, poiché in questa fase non è ancora noto molto a riguardo del progetto 3. Post-Architecture: si giunge alla fase di sviluppo tradizionale; si ottiene la stessa precisione di COCOMO 1; vengono usati LOC, Function Points e linguaggio con 17 cost drivers e 5 fattori di scala, che sostituiscono i fattori del modello precedente e i modelli Organic, Semidetachede Embedded Inoltre, il modello COCOMO II utilizza modelli non lineari per riuso e reingegnerizzazione permette il trattamento delle economie di scala apporta modiche ai moltiplicatori originari si avvale di un modello Bayesiano per i parametri del modello valutati da esperti

20 20 13 Linguaggio Z 11 CORBA L'OMG (Object Management Group), decise di promuovere il CORBA (Common Object Request Broker Architecture) una architettura distribuita orientata algi oggetti. Usando CORBA, un client può in modo trasparente (es.: senza conoscere l'implementazione del server in dettaglio) invocare un metodo su un server in due modi: in modo statico oppure tramite una invocazione dinamica. 12 DFD Un DFD (data ow diagram) è una rappresentazione graca di un usso di dati attraverso un sistema. Un diagramma di usso può essere utilizzato per visualizzare il data processing. 13 Linguaggio Z È un linguaggio per la specica formale, il quale usa la notazione matematica per descrivere in un modo preciso le proprietà e le informazioni che un sistema deve avere, senza conoscere in che modo queste proprietà vengono archiviate [7]; descrive che cosa il sistema deve fare senza sapere come [4]. Una importante caratteristica del linguaggio Z è quella di decomporre la specica in piccole parti chiamati schemas. Gli schema sono usati per descrivere aspetti statici e dinamici. Gli aspetti statici includono: lo stato che può essere occupato, le relazioni tra invarianti che sono mantenute quando un sistema si muove da uno stato all'altro. Gli aspetti dinamici includono: le operazioni possibili, le relazioni tra i loro input e output, i cambiamenti di stato.

21 13 Linguaggio Z Esempio - Denizione sistema Denire formalmente tramite il linguaggio Z un software che gestisce il nome e la data di compleanno di un database di persone. BirthdayBook known: P NAME birthday: NAME DATE known: dom Birthday known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno L'ultima riga, è l'invariante in quanto è una relazione vera in ogni stato del sistema. Un possibile stato del sistema è dato da: known = { Primo, Michele, Claudia } birthday = { Primo 25Mar, Michele 20Dec, Claudia 20Dec }. L'invariate è rispettato in quanto il dominio dei birthday record è esattamente uguale a quello di known cioè Esempio - Add Aggiungiamo al sistema la possibilità di inserire nuovi dati. Lo schema è AddBirthday. AddBirthday BirthdayBook name?: NAME date?: DATE name? / known Birthday' =Birthday {name? date? } known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno

22 22 14 Diagrammi UML 14 Diagrammi UML UML è un linguaggio di progettazione; UML è una evoluzione di modelli già esistenti, forti anità con ER (Entity - Relationship), FC (Flow Chart), modelli object oriented. Diagrammi UML: Livello logico: diagramma dei casi d'uso (use case) diagramma delle classi (class) diagramma di sequenza (sequence) diagramma di collaborazione (collaboration) diagramma di transizione di stato (state) diagramma delle attività (activity) Livello sico: diagramma dei componenti (component) diagramma di distribuzione dei componenti (deployment) 14.1 Diagramma casi d'uso Questi descrivono l'interazione tra attori e sistema, non la logica interna della funzione; sono infatti espressi in forma testuale, comprensibile anche per i non addetti ai lavori e possono essere deniti a livelli diversi (sistema o parti del sistema). Ragionare sui casi d'uso aiuta a scoprire i requisiti funzionali Diagramma delle classi Il diagramma delle classi, rappresenta le classi e gli oggetti che compongono il sistema, ed i relativi attributi ed operazioni [6, 1]. Specica, mediante le associazioni, i vincoli che legano tra loro le classi; può essere denito in fasi diverse (analisi, disegno di dettaglio) ed inoltre può rappresentare diverse tipologie di oggetti (oggetti business, oggetti di interfaccia,... ).

23 14 Diagrammi UML Diagramma delle sequenze Il diagramma delle sequenze, serve ad evidenziare il modo in cui uno scenario (uno specico percorso in un caso d'uso) viene risolto dalla collaborazione tra un insieme di oggetti; specica la sequenza dei messaggi che gli oggetti si scambiano inoltre può specicare nodi decisionali e iterazioni. Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso Diagramma delle collaborazioni Il diagramma delle collaborazioni, specica gli oggetti che collaborano tra loro in un dato scenario, ed i messaggi che si indirizzano. La sequenza dei messaggi è meno evidente che nel diagramma di sequenza, mentre sono più evidenti i legami tra gli oggetti; può essere utilizzato in fasi diverse (analisi, disegno di dettaglio), e rappresentare diverse tipologie di oggetti Diagramma di stato Specica il ciclo di vita degli oggetti di una classe, denendo le regole che lo governano; quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri). Come risultato di un evento l'oggetto può passare ad un nuovo stato (transizione) Diagramma delle attività Serve a rappresentare sistemi di workow, oppure la logica interna di un processo (di qualunque livello, dai business process ai processi di dettaglio). Permette di rappresentare processi paralleli e la loro sincronizzazione; è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività Diagramma dei componenti Evidenzia l'organizzazione e le dipendenze esistenti tra componenti; i componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia ben specicata, inoltre i componenti (come a livello logico le classi) possono essere raggruppati in package.

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

Rational Unified Process Introduzione

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

Dettagli

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

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

Dettagli

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

Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software

Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software 1 Ingegneria del software L istituzione e l impiego di principi ingegneristici fondati, allo scopo di ottenere

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

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

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

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 ciclo di vita del software

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

Dettagli

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

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

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

Dettagli

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT Executive Master in Governance dei Progetti e dei Servizi IT GPSIT OBIETTIVI Il Master ha l obiettivo di formare executive e professional nella governance dei progetti e dei servizi IT, integrando quelle

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

IT Service Management, le best practice per la gestione dei servizi

IT Service Management, le best practice per la gestione dei servizi Il Framework ITIL e gli Standard di PMI : : possibili sinergie Milano, Venerdì, 11 Luglio 2008 IT Service Management, le best practice per la gestione dei servizi Maxime Sottini Slide 1 Agenda Introduzione

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

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

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

Dettagli

Introduzione al Project Management. AIPA Area Monitoraggio e Verifiche

Introduzione al Project Management. AIPA Area Monitoraggio e Verifiche Introduzione al Project Management AIPA Area Monitoraggio e Verifiche Contenuti del corso Impostazione del progetto; Pianificazione delle attività, risorse e costi; Coordinamento e controllo durante le

Dettagli

Project Management dei Progetti Software

Project Management dei Progetti Software Project Management dei Progetti Software 1 Obiettivi della lezione Il Project Management Tecniche per la stima dei costi sw Misurare le dimensioni di un progetto sw Linee di codice Function Point Stima

Dettagli

UML Component and Deployment diagram

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

Dettagli

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra A seguire alcune proposte di tirocini/tesi in tre ambiti dell ingegneria del software (non del tutto scorrelati): (1) Model-driven driven

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

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

Dettagli

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

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

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

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

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

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

Studio di retribuzione 2014

Studio di retribuzione 2014 Studio di retribuzione 2014 TECHNOLOGY Temporary & permanent recruitment www.pagepersonnel.it EDITORIALE Grazie ad una struttura costituita da 100 consulenti e 4 uffici in Italia, Page Personnel offre

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Dalla Mappatura dei Processi al Business Process Management

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

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

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

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

UNIVERSITÀ DEGLI STUDI DI GENOVA

UNIVERSITÀ DEGLI STUDI DI GENOVA UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA Prova Finale GESTIONE DELLA TRANSIZIONE SECONDO LO STANDARD ITIL ITIL SERVICE TRANSITION

Dettagli

Ricognizione di alcune Best Practice

Ricognizione di alcune Best Practice Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione Manuale di riferimento Ricognizione di alcune Best Practice applicabili

Dettagli

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML

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

Dettagli

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 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese CMMI-Dev V1.3 Capability Maturity Model Integration for Software Development, Version 1.3 Roma, 2012 Agenda Che cos è il CMMI Costellazione di modelli Approccio staged e continuous Aree di processo Goals

Dettagli

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

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

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Prolog: aritmetica e ricorsione

Prolog: aritmetica e ricorsione Capitolo 13 Prolog: aritmetica e ricorsione Slide: Aritmetica e ricorsione 13.1 Operatori aritmetici In logica non vi è alcun meccanismo per la valutazione di funzioni, che è fondamentale in un linguaggio

Dettagli

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

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

Dettagli

Progettazione Orientata agli Oggetti

Progettazione Orientata agli Oggetti Progettazione Orientata agli Oggetti Sviluppo del software Ciclo di vita del software: comprende tutte le attività dall analisi iniziale fino all obsolescenza (sviluppo, aggiornamento, manutenzione) Procedimento

Dettagli

Presentazione per. «La governance dei progetti agili: esperienze a confronto»

Presentazione per. «La governance dei progetti agili: esperienze a confronto» Presentazione per «La governance dei progetti agili: esperienze a confronto» Pascal Jansen pascal.jansen@inspearit.com Evento «Agile Project Management» Firenze, 6 Marzo 2013 Agenda Due parole su inspearit

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

MASTER UNIVERSITARI CORSI di PERFEZIONAMENTO CORSI di FORMAZIONE AVANZATA

MASTER UNIVERSITARI CORSI di PERFEZIONAMENTO CORSI di FORMAZIONE AVANZATA Allegato 1 al bando di gara SCUOLA TELECOMUNICAZIONI FF.AA. CHIAVARI REQUISITO TECNICO OPERATIVO MASTER UNIVERSITARI CORSI di PERFEZIONAMENTO CORSI di FORMAZIONE AVANZATA MASTER DI 2 LIVELLO 1. DIFESA

Dettagli

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e'

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il continuous improvement ed e' ITIL v3 ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e' giusto che lo applichi anche a se' stessa... Naturalmente una

Dettagli

Le caratteristiche di interoperabilità del Terrapack 32 M

Le caratteristiche di interoperabilità del Terrapack 32 M I T P E l e t t r o n i c a Le caratteristiche di interoperabilità del Terrapack 32 M M. Guerriero*, V. Ferrara**, L. de Santis*** * ITP Elettronica ** Dipartimento di Ingegneria Elettronica Univ. La Sapienza

Dettagli

STS. Profilo della società

STS. Profilo della società STS Profilo della società STS, Your ICT Partner Con un solido background accademico, regolari confronti con il mondo della ricerca ed esperienza sia nel settore pubblico che privato, STS è da oltre 20

Dettagli

LE NOVITÀ DELL EDIZIONE 2011 DELLO STANDARD ISO/IEC 20000-1 E LE CORRELAZIONI CON IL FRAMEWORK ITIL

LE NOVITÀ DELL EDIZIONE 2011 DELLO STANDARD ISO/IEC 20000-1 E LE CORRELAZIONI CON IL FRAMEWORK ITIL Care Colleghe, Cari Colleghi, prosegue la nuova serie di Newsletter legata agli Schemi di Certificazione di AICQ SICEV. Questa volta la pillola formativa si riferisce alle novità dell edizione 2011 dello

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

IT Service Management

IT Service Management IT Service Management L'importanza dell'analisi dei processi nelle grandi e medie realtà italiane Evento Business Strategy 2.0 Firenze 25 settembre 2012 Giovanni Sadun Agenda ITSM: Contesto di riferimento

Dettagli

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO REGIONE BASILICATA PROCEDURA NEGOZIATA PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, REALIZZAZIONE E GESTIONE DEL SISTEMA INTEGRATO SERB ECM DELLA REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06)

Dettagli

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI?

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? Le offerte di public cloud proliferano e il private cloud è sempre più diffuso. La questione ora è come sfruttare

Dettagli

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

Dettagli

ITIL v3, il nuovo framework per l ITSM

ITIL v3, il nuovo framework per l ITSM ITIL v3, il nuovo framework per l ITSM ( a cura di Stefania Renna ITIL - IBM) Pag. 1 Alcune immagini contenute in questo documento fanno riferimento a documentazione prodotta da ITIL Intl che ne detiene

Dettagli

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

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

Dettagli

IT FINANCIAL MANAGEMENT

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

Dettagli

IL PROGETTO MINDSH@RE

IL PROGETTO MINDSH@RE IL PROGETTO MINDSH@RE Gruppo Finmeccanica Attilio Di Giovanni V.P.Technology Innovation & IP Mngt L'innovazione e la Ricerca sono due dei punti di eccellenza di Finmeccanica. Lo scorso anno il Gruppo ha

Dettagli

agility made possible

agility made possible SOLUTION BRIEF CA IT Asset Manager Come gestire il ciclo di vita degli asset, massimizzare il valore degli investimenti IT e ottenere una vista a portfolio di tutti gli asset? agility made possible contribuisce

Dettagli

Convegno 6 giugno 2013 Federlazio Frosinone

Convegno 6 giugno 2013 Federlazio Frosinone Convegno 6 giugno 2013 Federlazio Frosinone pag. 1 6 giugno 2013 Federlazio Frosinone Introduzione alla Business Intelligence Un fattore critico per la competitività è trasformare la massa di dati prodotti

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

Progetto BPR: Business Process Reengineering

Progetto BPR: Business Process Reengineering Progetto BPR: Business Process Reengineering Riflessioni frutto di esperienze concrete PER LA CORRETTA INTERPRETAZIONE DELLE PAGINE SEGUENTI SI DEVE TENERE CONTO DI QUANTO ILLUSTRATO ORALMENTE Obiettivo

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Storia ed evoluzione dei sistemi ERP

Storia ed evoluzione dei sistemi ERP Storia ed evoluzione dei sistemi ERP In questo breve estratto della tesi si parlerà dei sistemi ERP (Enterprise Resource Planning) utilizzabili per la gestione delle commesse; questi sistemi utilizzano

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

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

Dettagli

Le variabili. Olga Scotti

Le variabili. Olga Scotti Le variabili Olga Scotti Cos è una variabile Le variabili, in un linguaggio di programmazione, sono dei contenitori. Possono essere riempiti con un valore che poi può essere riletto oppure sostituito.

Dettagli

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo White paper La Process Intelligence migliora le prestazioni operative del settore assicurativo Pagina 2 Sintesi

Dettagli

ITIL. Introduzione. Mariosa Pietro

ITIL. Introduzione. Mariosa Pietro ITIL Introduzione Contenuti ITIL IT Service Management Il Servizio Perchè ITIL ITIL Service Management life cycle ITIL ITIL (Information Technology Infrastructure Library) è una raccolta di linee guida,

Dettagli

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONNECTING FIRST AND SECOND LIFE Università degli studi di Catania Facoltà di Ingegneria 26 Gennaio 2009 Sommario 1 Introduzione 2 Middleware Middleware:

Dettagli

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

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

Dettagli

Metadati e Modellazione. standard P_META

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

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

PASSIONE PER L IT PROLAN. network solutions

PASSIONE PER L IT PROLAN. network solutions PASSIONE PER L IT PROLAN network solutions CHI SIAMO Aree di intervento PROFILO AZIENDALE Prolan Network Solutions nasce a Roma nel 2004 dall incontro di professionisti uniti da un valore comune: la passione

Dettagli

Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio

Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio Umberto Sartore - 578209 Relatore: Prof. Ennio Buro UNIVERSITA DEGLI STUDI DI PADOVA FACOLTA DI INGEGNERIA CORSO

Dettagli

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

Valutazione comparativa di applicazioni open source per il Business Process Management

Valutazione comparativa di applicazioni open source per il Business Process Management Valutazione comparativa di applicazioni open source per il Business Process Management Abstract Uno dei passi fondamentali della metodologia USBD (Unified Scenario-Based Design) è la modellazione dei processi

Dettagli

B.P.S. Business Process Server ALLEGATO C10

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

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Sistemi di gestione dei dati e dei processi aziendali. Information Technology General Controls

Sistemi di gestione dei dati e dei processi aziendali. Information Technology General Controls Information Technology General Controls Indice degli argomenti Introduzione agli ITGC ITGC e altre componenti del COSO Framework Sviluppo e manutenzione degli applicativi Gestione operativa delle infrastrutture

Dettagli

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it ISO 9001: 2008 Profilo Aziendale METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it Sede legale: * Viale Brodolini, 117-60044 - Fabriano (AN) - Tel. 0732.251856 Sede amministrativa:

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java]

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java] Desideriamo realizzare una applicazione web che ci consenta di calcolare il fattoriale di un numero. L'esercizio in sé non particolarmente difficile, tuttavia esso ci consentirà di affrontare il problema

Dettagli

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS Integrazione Ecad Mcad Ecad - MENTOR GRAPHICS MENTOR GRAPHICS - PADS La crescente complessità del mercato della progettazione elettronica impone l esigenza di realizzare prodotti di dimensioni sempre più

Dettagli

Realizzare un architettura integrata di Business Intelligence

Realizzare un architettura integrata di Business Intelligence Realizzare un architettura integrata di Business Intelligence Un sistema integrato di Business Intelligence consente all azienda customer oriented una gestione efficace ed efficiente della conoscenza del

Dettagli

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult KM, ECM e BPM per creare valore nell impresa Giovanni Marrè Amm. Del., it Consult Terminologia Ci sono alcuni termini che, a vario titolo, hanno a che fare col tema dell intervento KM ECM BPM E20 Enterprise

Dettagli

Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi

Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi alternative: function nome { lista-comandi } oppure nome ( ) {

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE Pag. 1 di 14 INDICE 1. Glossario... 3 2. il servizio SPCoop - Ricezione... 5 3. Il web-service RicezioneFatture... 8 3.1 Operazione RiceviFatture... 9 3.1.1

Dettagli

How to Develop Accessible Linux Applications

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

Dettagli

1.1 ITIL e la gestione dei servizi IT

1.1 ITIL e la gestione dei servizi IT Via Turati 4/3, 16128 Genova Tel. 348/4103643 Fax 010/8932429 ITIL (Information Technology Infrastructure Library) 1.1 ITIL e la gestione dei servizi IT In un mercato in cui il successo delle aziende è

Dettagli

1 EJB e Portal Component Object http://desvino.altervista.org

1 EJB e Portal Component Object http://desvino.altervista.org 1 EJB e Portal Component Object http://desvino.altervista.org In questo tutorial studiamo come sfruttare la tecnologia EJB, Enterprise JavaBean, all interno del SAP Netweaver Portal. In breve, EJB è un

Dettagli

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

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

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis 2 Intervento immediato con Bosch Intelligent Video Analysis Indipendentemente da quante telecamere il sistema utilizza, la sorveglianza

Dettagli

Permutazione degli elementi di una lista

Permutazione degli elementi di una lista Permutazione degli elementi di una lista Luca Padovani padovani@sti.uniurb.it Sommario Prendiamo spunto da un esercizio non banale per fare alcune riflessioni su un approccio strutturato alla risoluzione

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli