Il processo di sviluppo

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Il processo di sviluppo"

Transcript

1 Il processo di sviluppo Processo di sviluppo software = framework all'interno del quale si svolgono le attività necessarie per produrre software di alta qualità. E' il modo in cui viene organizzato e praticato lo sviluppo dei sistemi software. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modifica 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. In modo consapevole o meno, ogni sviluppatore (o gruppo di sviluppatori) software ha un proprio processo di sviluppo - un proprio modo di lavorare. Basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in cui si trova ad operare. La storia dei successi (e soprattutto degli insuccessi) dei progetti di sviluppo software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i propri limiti. E che un processo di sviluppo inadeguato alla concrete esigenze dello specifico progetto può condurre al fallimento del progetto stesso, o comunque all'insoddisfazione dei clienti / utenti e degli stessi sviluppatori. 1

2 Il processo di sviluppo A Common Process Framework Common process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities 2

3 Il processo di sviluppo Un generico processo di sviluppo software è costituito da uno o più set di Attività portanti (Framework Activities), cioè dalle attività necessarie per garantire l'avanzamento del processo di produzione del software. Le attività portanti rappresentano il fondamento del processo di sviluppo, in quanto comprendono le attività direttamente legate alla realizzazione del prodotto software. Fra queste possiamo citare: la suddivisione del prodotto in moduli la codifica il controllo di avanzamento la verifica del livello qualitativo del software il bug fixing 3

4 Il processo di sviluppo Alle attività portanti si affiancano le Attività ausiliarie (Umbrella Activities), che rappresentano l'insieme di tutte le attività non direttamente collegate alle fasi produttive, ma che concorrono con esse al raggiungimento dell'obiettivo. Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management 4

5 Capability Maturity Model Il Modello di Maturità delle Capacità (CMM - Capability Maturity Model) individua un insieme di capacità corrispondenti al livello di maturità di processo di una software house. Misura esclusivemente la validità di processo, dunque non fornisce una valutazione della validità tecnica e/o architetturale del prodotto dell'azienda. Il CMM è stato elaborato dal Software Engineering Institute nel 1993, sulla base del processo di sviluppo descritto nello standard Mil-Std-498, sviluppato negli Stati Uniti in ambito militare.. Il CMM prevede 5 livelli di valutazione, ad ognuno dei quali sono associate più Key Process Areas (KPA); ogni livello comprende tutte le caratteristiche dei livelli precedenti. 1. Livello Iniziale: il processo di svluppo è definito di volta in volta risulta confuso, spesso non è nemmeno definito la riuscita del progetto dipende dalle capacità individuali degli sviluppatori KPA: nessuna! 5

6 Capability Maturity Model 2. Livello Ripetibile: nell'azienda esistono processi basilari per la gestione dei progetti, al fine di tenere sotto controllo costi, tempi e soddisfacimento dei requisiti. le metodologie usate in progetti di successo precedenti vengono ripetute in progetti successivi. KPA: Gestione Garanzia di qualità del sw Gestione dei sottocontratti (Outsourcing) Controllo e sorveglianza del progetto Pianificazione del progetto Gestione dei requisiti 6

7 Capability Maturity Model 3. Livello Definito: il processo è conforme ad uno standard aziendale definito, stabile e documentato sia per quanto riguarda le attività portanti che per quanto riguarda le attività ausiliarie. KPA: Revisioni Coordinamento dei gruppi Ingegneria del prodotto sw Gestione integrata del sw Programmi di addestramento Definizione del processo azindale Obiettivo primario del processo aziendale 4. Livello Gestito: sia il prodotto sia il processo software sono valutati quantitativamente e qualitativamente sulla base di misure dettagliate. KPA: Gestione della qualità del software Gestione quantitativa del processo 7

8 Capability Maturity Model 5. Livello Ottimizzato: utilizzo di tecnologie e metodologie innovative al fine di raggiungere un livello ottimo di gestione del processo software e sviluppo del prodotto. KPA: Gestione del cambiamento nel processo Gestione del cambiamento tenologico Prevenzione dei difetti 8

9 Modelli di processo La strategia adottata da un azienda per gestire il processo di sviluppo software (comprendente metodologie, tecniche e strumenti) è denominata Modello di Processo o Paradigma di Ingegneria del Software dell azienda. Qualunque modello di processo adotti un azienda, esistono elementi comuni. problem definition status quo technical development solution integration 9

10 Modelli di processo (L. Raccoon, The chaos model end the chaos lifecycle, ACM Software Engineering Notes, vol.20 n.1, 1995) Lo status quo dello sviluppo software viene modificato attraverso delle iterazioni che prevedono: La definizione del problema Lo sviluppo tecnico L integrazione della soluzione Una iterazione produce un nuovo status quo che può essere modificato con successive iterazioni. Il ciclo di Raccoon è indipendente dal modello di processo e dalla tecnologia adottata; le attività portanti ed accessorie descritte in precedenza si possono facilmente ascrivere ad una delle fasi. Ad esempio, codifica e bug fixing appartengono alla fase di sviluppo tecnico, mentre la redazione di documentazione di progetto appartiene alla fase di integrazione. 10

11 Modelli di processo Possiamo osservare che il ciclo di Raccoon si applica a più livelli di dettaglio: a livello dell intera applicazione, a livello di progettazione dell infrastruttura di base, di progettazione di componenti, fino allo sviluppo di parti di codice. Qualunque siano il modello di processo e le tecnologie adottate, le fasi di definizione del problema, sviluppo tecnico e integrazione della soluzione coesistono ad un certo livello di dettaglio. Durante il cammino verso lo sviluppo di un applicazione completa, le quattro fasi si applicano ricorsivamente dalla raccolta dei requisiti utente fino ai più piccoli dettagli implementativi. Il risultato è una visione frattale del processo di sviluppo software! 11

12 Modelli di processo Il Modello Sequenziale Lineare Il Modello Sequenziale Lineare trae origine dal Modello a Cascata, originariamente proposto da Royce nel (W.Royce, "Managing the Development of Large Software Systems", Proceedings of IEEE Wescon, 1970) System/information engineering analysis design code test 12

13 Modelli di processo Il Modello Sequenziale Lineare Il progetto è organizzato in una sequenza di fasi, ciascuna delle quali produce un output che costituisce l'input per la fase successiva. All'inizio di ciascuna fase si verifica la qualità del lavoro effettuato nella fase precedente, con possibilità di ricicli per modifica Le fasi individuate da Royce prevedono: Strutturazione e modellazione del sistema e dei dati Il modello sequenziale lineare prevede una fase iniziale di macro-analisi durante la quale vengono esaminati tutti i requisiti e viene progettata l infrastruttura dell applicazione e dei dati. Il processo viene raffinato nelle due fasi successive di analisi e progettazione. Analisi dei requisiti Prevede la definizione dettagliata (e relativa documentazione) di funzionalità, prestazioni, interfacce del software. 13

14 Modelli di processo Il Modello Sequenziale Lineare Progettazione La fase di progettazione traduce i requisiti utente in una modellazione del software, ossia in una documentazione che consenta di valutare la qualità del software prime che inizi la codifica. Si articola in modellazione di architettura, struttura dati, interfacce ed algoritmi di elaborazione. Codifica Testing Il modello sequenziale lineare si applica sia alla realizzazione iniziale di un software, sia alla sua manutenzione, cioè alla revisione del software stesso al fine di correggere errori o soddisfare le mutate esigenze del committente. 14

15 Modelli di processo Il Modello Sequenziale Lineare Diffusione del processo a cascata E' probabilmente il processo di sviluppo software più diffuso al mondo, anche perché segue il modello della catena di montaggio tipico della produzione industriale della prima metà del novecento. Ma è considerato irrimediabilmente obsoleto, ed è raro trovare esperti che lo raccomandino ancora. I settori economici per i quali la qualità e produttività dei progetti di sviluppo software sono più critici hanno da tempo abolito la pratica dello sviluppo a cascata, in quanto troppo rischioso. Vantaggi E' molto semplice da capire, quasi intuitivo (anche per chi non ha mai sviluppato software): prima si raccolgono tutti i requisiti, poi si fa tutta l'analisi, poi tutto il design, poi tutta la codifica,... E' semplicissimo organizzare il piano di progetto (non che sia facile pianificare le date di conclusione delle fasi, ma non ci sono dubbi sulla sequenza delle fasi stesse). Si adatta perfettamente a logiche organizzative e politiche del personale basate su una divisione del lavoro accentuata. 15

16 Modelli di processo Il Modello Sequenziale Lineare Svantaggi E' altamente rischioso. Le prime verifiche concrete, in termini di risultati visibili e comprensibili da committenti e utenti, arrivano verso la fine del progetto, nel periodo finale della fase di test. E se ci si accorge che qualcosa non funziona (accade...), ossia che il sistema realizzato non corrisponde ai requisiti, impliciti ed espliciti, i tempi ed i costi del progetto possono crescere in misura notevole. Si basa su alcune assunzioni, il più delle volte sbagliate: 1. Che sia possibile, nella fase iniziale del progetto, chiarire tutti i requisiti del sistema. E che sia possibile farlo senza discutere con il committente e le parti interessate nel merito delle soluzioni concrete, senza verificare l'accordo con la presentazione di prototipi utilizzabili. Questa assunzione sbagliata può provocare due effetti: - che si raggiunga un accordo sulla carta, ma che non ci sia un accordo effettivo sul merito di problemi (e che non ci si renda conto della cosa fino alla verifica finale) 16

17 Modelli di processo Il Modello Sequenziale Lineare - che si raggiunga la "paralisi dell'analisi", con il progetto che non riesce a chiarire alcune aree di ambiguità e l'impossibilità per il committente e le parti interessate di fornire i chiarimenti richiesti. 2. Che una volta ottenuto l'accordo sui requisiti (tipicamente, con la produzione di alcuni documenti testuali che specificano, in termini astratti, le funzionalità del sistema), i requisiti stessi non cambino più fino alla fine del progetto. Può essere vero, per progetti molto, molto brevi. Ma non è certamente vero per progetti di complessità media o elevata. 3. Che sia possibile definire i requisiti, e stimare tempi e costi del progetto, senza possedere la competenza necessaria sugli aspetti tecnici ed implementativi. Questo non è in sé un limite del processo di sviluppo a cascata, ma della sua attuazione concreta in organizzazioni nelle quali esiste una forte divisione del lavoro. In molte realtà, la definizione dei requisiti viene effettuata da persone, nel ruolo di analisti, che non hanno le competenze tecniche necessarie allo sviluppo software. Oppure che avevano, anni addietro, competenze tecniche, ma basate sull'utilizzo di tecnologie diverse da quelle utilizzate nel progetto. E che non sono quindi in grado, da sole, di produrre stime attendibili. 17

18 Modelli di processo Il Modello Sequenziale Lineare Possiamo quindi concludere che raramente un progetto reale si adatta allo schema sequenziale. Nota: Royce era consapevole dei limiti del modello a cascata, e il suo articolo originale proponeva dei correttivi, che purtroppo hanno avuto una diffusione assai limitata. 18

19 Modelli di processo Il Modello Incrementale Il Modello Incrementale è una derivazione del processo di sviluppo a cascata. 19

20 Modelli di processo Il Modello Incrementale (B. Boehm, Software Engineering Economics, Prentice-Hall 1981) Il modello incrementale prevede che, una volta completata la fase di analisi, venga effettuata una attività di design dell'architettura del sistema. Vengono, cioè, effettuate le scelte "di alto livello" relative a: strutturazione del sistema in macroparti distinte (sottosistemi) responsabilità di ciascun sottosistema modalità di dialogo tra i diversi sottosistemi (interfacce). A questo punto vengono definite delle priorità di realizzazione, sulla base di due aspetti: priorità di natura funzionale (relativa alle esigenze dei committenti e delle parti interessate) priorità di natura architetturale (se un sottosistema A necessita del sottosistema B per funzionare, B ha una priorità superiore) Sulla base delle priorità definite, il progetto viene articolato in una serie di sottoprogetti realizzativi, ciascuno dei quali produrrà uno o più sottosistemi (parti del sistema complessivo). 20

21 Modelli di processo Il Modello Incrementale I sottoprogetti realizzativi potranno essere condotti in sequenza rigida (uno dopo l'altro), oppure essere condotti parzialmente in parallelo (con sovrapposizioni temporali). Diffusione del processo incrementale Viene spesso utilizzato, in progetti di complessità medio-grande, come variante di un processo a cascata, in quanto costituisce un modo di ridurne i rischi. Vantaggi Rispetto al processo a cascata, permette di arrivare a consegnare qualcosa di concreto prima di aver completato l'intero sistema. In questo modo si ottengono feedback (riscontri) concreti, con indicazioni utilizzabili anche nei sottoprogetti realizzativi ancora in corso o successivi. E si riducono i rischi di insuccesso. L'articolazione del piano di progetto è più complessa (rispetto al processo di sviluppo a cascata), ma permette una maggiore flessibilità nell'assegnazione delle persone ai compiti progettuali, quando i sottoprogetti vengono pianificati con una parziale sovrapposizione temporale. 21

22 Modelli di processo Il Modello Incrementale Svantaggi Condivide con il processo a cascata le due assunzioni - erronee - che: sia possibile definire tutti i requisiti alla partenza del progetto, senza entrare con i committenti e le altre parti interessate nel merito delle soluzioni concrete i requisiti non cambino dopo che sono stati concordati 22

23 Modelli di processo Il Modello Prototipale Il principale limite del modello a cascata è che l utente deve attendere fino al termine della fase di sviluppo prima di poter valutare il prodotto. Se il committente non è in grado di definire con sufficiente chiarezza i propri requisiti, il modello a cascata si rivela inadeguato. Il Modello Prototipale pone l accento sul ruolo centrale del committente nella definizione dell applicazione, e pertanto agevola la definizione dei requisiti. listen to customer build/revise mock-up customer test-drives mock-up 23

24 Modelli di processo Il Modello Prototipale Il modello prototipale prevede: Una prima fase di raccolta dei requisiti analoga a quella del modello a cascata, ma più rapida ed informale, volta a definire dei requisiti di massima. Una fase di progettazione del prototipo, sulla base dei requisiti (incompleti) raccolti nella fase precedente. La progettazione è in genere incentrata sull interfaccia utente. Una fase di realizzazione di un prototipo. Il prototipo deve soddisfare i requisiti noti al momento dello sviluppo, ma per la sua realizzazione non si è tenuti a rispettare alcune caratteristiche fondamentali del software di qualità: es. prestazioni, qualità del codice, riusabilità, manutenibilità. Lo scopo del prototipo è solo quello permettere al committente di valutare l aderenza dell applicazione alle proprie necessità. Il feedback dell utente relativamente al funzionamento del prototipo genera un successivo ciclo durante il quale il prototipo viene raffinato. 24

25 Modelli di processo Il Modello Prototipale Una volta raggiunto l accordo con il committente riguardo alla definizione delle specifiche, è necessario passare ad una fase di ingegnerizzazione del prodotto, al fine di poter consegnare un prodotto di qualità. Dal momento che il prototipo è stato realizzato per approssimazioni successive senza particolare attenzione alla sua architettura, la fase di ingegnerizzazione prevede di gettare via il prototipo! Vantaggi Il committente vede crescere il prodotto, quindi è molto improbabile consegnare un prodotto finale che non soddisfi il committente. Lo sviluppatore è molto agevolato nella fase di negoziazione dei requisiti I tempi di sviluppo sono molto rapidi (in apparenza!) Svantaggi La tentazione di considerare il prototipo come un prodotto è molto forte sia l utente che lo sviluppatore tendono a farlo. Il risultato è che spesso si rinuncia all ingegnerizzazione del prodotto, e si consegna un applicazione funzionante, ma di scarsa qualità. 25

26 Modelli di processo Il Modello Prototipale Il committente ha per le mani in tempi rapidi un oggetto funzionante, che soddisfa le sue esigenze, ed è portato a pensare che con pochi ritocchi sia possibile trasformarlo in un prodotto realmente operativo. Le difficoltà (ed i conseguenti costi) della fase di ingegnerizzazione sono percepiti con difficoltà dal committente si generano inevitabilmente dei contrasti. 26

27 Modelli di processo Il Modello a Spirale Il Modello a Spirale prevede uno sviluppo del software in versioni crescenti. Pla nning Risk Analysis Customer Communication Eng ine e ring Customer Eva lua tio n Construction & Release 27

28 Modelli di processo Il Modello a Spirale (Barry Boehm, "A Spiral Model of Software Development and Enhancement", in Computer, vol.21 n.5, 1988) Il modello a spirale è il più diffuso modello di sviluppo di tipo Iterativo. La spirale parte dal centro, con un insieme di obiettivi e requisiti iniziali per il progetto. Ogni ciclo (o iterazione) comporta l'effettuazione di una serie di attività, dette task regions: Comunicazione con il cliente Pianificazione Analisi dei rischi Progettazione Costruzione e rilascio Valutazione da parte del cliente Le task regions, nel loro insieme, comprendono le fasi tradizionali del modello sequenziale lineare: analisi dei requisiti progettazione 28

29 Modelli di processo Il Modello a Spirale codifica test Cioè le stesse attività che, in un processo di sviluppo a cascata, sono considerate come delle fasi da svolgersi in sequenza rigida, una dopo l'altra. Nel processo iterativo, in ogni iterazione (in ogni ciclo della spirale) vengono svolte le medesime tipologie di attività. L'articolazione di un progetto iterativo è guidata non da una rigida sequenza di fasi predefinite, ma da una gestione sistematica dei rischi di progetto, per arrivare alla loro progressiva diminuzione. All'inizio di un progetto di sviluppo software, i rischi sono tipicamente molto elevati. Manca la chiarezza sui requisiti, le scelte sulle tecnologie e sulla strutturazione del sistema (le scelte architetturali) sono ipotesi non ancora consolidate. In alcuni casi, sono state scelte tecnologie innovative, per le quali manca però una sufficiente esperienza nel gruppo di progetto. In altri, anche a fronte di tecnologie conosciute, esistono incertezze legate alla necessità di fare fronte a un numero di utilizzatori contemporanei molto elevato, o a volumi di dati mai gestiti in precedenza. 29

30 Modelli di processo Il Modello a Spirale Ogni iterazione, in un progetto iterativo, ha lo scopo di ridurre i rischi di progetto. Inizialmente, tramite la costruzione di prototipi. Prototipi di interazione (interfacce utente), per affrontare i rischi legati all'incertezza sui requisiti. Prototipi architetturali (realizzazione e test di aspetti infrastrutturali), per affrontare i rischi legati alla scelta delle tecnologie ed i dubbi sulla strutturazione del sistema. Successivamente, quando i rischi principali sono stati messi sotto controllo, ogni iterazione ha lo scopo di costruire, in modo progressivo, nuove porzioni del sistema, via via integrate con le precedenti, e di verificarle con il committente e le altre parti interessate. Sotto questo profilo, esiste più di un'affinità con il processo di sviluppo incrementale; ma anche una differenza significativa. Un processo iterativo, infatti, prevede il cambiamento di requisiti in corso d'opera. Prevede, in particolare, la "nascita" di nuovi requisiti espressi dal committente e dalle altre parti interessate al sistema come effetto dell'utilizzo del sistema stesso (delle sue parti già rese disponibili agli utilizzatori). 30

31 Modelli di processo Il Modello a Spirale Vantaggi Gestione sistematica dei rischi di progetto, attraverso iterazioni volte alla loro progressiva riduzione. Rispetto al processo di sviluppo a cascata, salvo eccezioni, maggiore qualità dei prodotti, e maggiore produttività dei progetti (costi e tempi inferiori). Svantaggi La pianificazione dei progetti condotti in modo iterativo è più complessa, e meno "banale". All'inizio del progetto è impossibile prevedere esattamente il numero delle iterazioni, la durata di ogni singola iterazione, i suoi obiettivi specifici. Il piano di un processo iterativo evolve durante tutta la durata del progetto stesso, e richiede un controllo sistematico degli avanzamenti. Un punto cruciale per il successo di un progetto iterativo è la collaborazione sistematica tra committenti (e altre parti interessate) e gruppo di progetto. Da un lato, il gruppo di progetto deve fornire in modo sistematico visibilità sugli avanzamenti, in termini di prodotti concreti da valutare. Dall'altro, se i committenti (e le altre parti interessate) non forniscono periodicamente 31

32 Modelli di processo Il Modello a Spirale riscontri concreti ai prototipi ed alle porzioni di sistema realizzate dal gruppo di progetto, la progressiva riduzione dei rischi non ha luogo. Il modello a spirale è una strategia realistica per lo sviluppo di sistemi software di grandi dimensioni. Quanto più il successo dei progetti software è critico per gli obiettivi di un'organizzazione, tanto più è probabile che il processo di sviluppo adottato abbia caratteristiche di natura iterativa. I modelli iterativi sono particolarmente adatti allo svilupo di sistemi objectoriented. 32

33 Modelli di processo Extreme Programming I Processi Agili sono stati sviluppati a partire dalla seconda metà degli anni 90. Traggono origine dal Manifesto for Agile Software Development, che recita: "Stiamo scoprendo approcci migliori per sviluppare il software, praticandoli ed aiutando altri a praticarli. Grazie a questo lavoro siamo arrivati a ritenere importanti: Gli individui e le loro interazioni, più che i processi e gli strumenti Il software funzionante, più che una documentazione onnicomprensiva La collaborazione con il cliente, più che la negoziazione dei contratti Il rispondere ai cambiamenti, più che seguire un piano Cioè, mentre i concetti riportati a destra sono importanti, riteniamo che quelli riportati a sinistra siano più importanti. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.". 33

34 Modelli di processo Extreme Programming Nella loro maggioranza, i proponenti dei processi agili rigettano come burocratici ed inefficaci gli approcci tradizionali dell'ingegneria del software. Più interessante, però, è il fatto che molti degli autori più rilevanti del software engineering "tradizionale" (ad esempio Barry Boehm, Tom De Marco, Grady Booch) guardano ai processi agili come un fenomeno positivo. Tra i processi agili, il più diffuso è Extreme Programming (XP). (Kent Beck, Extreme Programming Explained, Addison-Wesley 2000) XP è una disciplina di sviluppo software basata su valori di semplicità, comunicazione e feedback continuo. XP si basa su una serie di pratiche (Practices). Le pratiche si integrano tra loro nel contesto di XP, ma è opportuno osservare che ciascuna di esse ha senso anche se applicata in modo autonomo, eventualmente nel contesto di un diverso processo di sviluppo. 34

35 Modelli di processo Extreme Programming 35

36 Modelli di processo Extreme Programming Whole Team XP rifiuta la suddivisione dei compiti in ruoli rigidi, e vede ogni persona coinvolta nel processo di sviluppo come parte integrante di una entità denominata Whole Team. Il committente fa parte del team e lavora fianco a fianco con gli sviluppatori per l intera durata del progetto. Il committente fornisce i requisiti e stabilisce le priorità; definisce inoltre i test di accettazione del prodotto, coadiuvato dagli analisti del team. Normalmente il team prevede anche un coach che ha l incarico di mantenere il team focalizzato sull obiettivo. Planning Game XP pone l accento su come indirizzare il progetto verso l obiettivo finale, man mano che ci si avvicina ad esso, piuttosto che sulla definizione esatta dell obiettivo finale in fase di analisi del progetto. XP prevede due diversi tipi di pianificazione: Release Planning fase nella quale il committente presenta al team i propri requisiti, che vangono valutati in termini di costi e difficoltà di realizzazione; la 36

37 Modelli di processo Extreme Programming stima è necessariamente imprecisa. In questa fase il team realizza un canovaccio di project plan, che sarà rivisto nelle fasi successive. Iteration Planning XP costruisce il codice mediante iterazioni di durata prefissata: due settimane. L obiettivo è produrre software funzionante (anche se non completo) al termine di ogni iterazione. Durante Iteration Planning, il committente presenta al team le features richieste per le due settimane successive; il team le valuta in termini di costi e fattibilità e definisce un piano per l iterazione. Gli obiettivi non pienamente soddisfatti al termine dell iterazione non sono presi in considerazione. In questo modo il committente vede crescere il prodotto ed è in grado di controllare il progetto attraverso le varie iterazioni. Customer Tests Il committente, insieme ad ogni feature richiesta, deve obbligatoriamente definire i test di accettazione. Il team costruisce delle procedure di test automatici che devono essere eseguiti ad ogni iterazione. 37

38 Modelli di processo Extreme Programming Small Releases Attraverso il meccanismo delle iterazioni, il team si pone l obiettivo di realizzare quanto più frequentemente possibile delle release parziali del prodotto da consegnare agli utenti finali. Simple Design Attitudine a scegliere costantemente la soluzione "più semplice" ad un dato problema, senza porsi il problema di anticipare i futuri cambiamenti. XP propone di mantenere il design della soluzione sempre adatto alle funzionalità correnti del sistema. Questo è possibile perché anche l architettura del sistema è considerata in costante evoluzione, attraverso degli incontri mirati previsti per l intera durata del progetto (in ogni iterazione e nelle fasi di realizzazione delle Small Releases). Questa attività di costante revisione dell architettura è denominata Refactoring. Pair Programming In XP, tutta l attività di stesura di codice è svolta da coppie di programmatori che lavorano fianco a fianco sulla stessa macchina. Questa pratica fa sì che 38

39 Modelli di processo Extreme Programming tutto il codice sorgente sia costantemente monitorato e validato da almeno un programmatore, con il risultato di produrre codice meglio progettato, più efficiente, meno incline agli errori. Può sembrare inefficiente avere due programmatori che fanno il lavoro di unosolo, ma alcune ricerche specifiche provano che due programmatori che lavorano in coppia producono gli stessi risultati (in termini di tempo e feature soddisfatte) che produrrebbero lavorando singolarmente, ma realizzano codice intrinsecamente migliore. Il Pair Programming ha anche l effetto di diffondere la conoscenza attraverso il team, se le coppie cambiano durante lo sviluppo del progetto. Test-driven Development In XP il processo di sviluppo deve essere ossessivamente guidato dai test: i test di feature devono essere realizzati (o quanto meno definiti) prima di sviluppare il relativo codice, e devono essere eseguiti con esito positivo al 100% ogni volta che un programmatore modifica una singola riga di codice sorgente. XP incoraggia anche i programmatori stessi a definire dei test per il modulo software da loro realizzato. 39

40 Modelli di processo Extreme Programming Continuous Integration In un progetto XP l integrazione dei vari moduli software che compongono la soluzione è garantita dalla generazione continua di build (8-10 volte al giorno, contro il ciclo di build settimanale adottato dalla maggior parte delle software house). Inoltre, la costruzione del build è a carico del team, non di terze persone meno coinvolte nel processo di sviluppo. In questo modo, a fronte di un carico di lavoro notevole per gli sviluppatori del team, si ha la garanzia che il prodotto sia costantemente funzionante e si evitano gli errori (spesso molto subdoli) dovuti all integrazione fra moduli. Collective Code Ownership Nei progetti XP, ogni coppia di programmatori può liberamente modificare porzioni di codice scritte da altri: la proprietà del codice è dell intero team, e non esistono moduli di esclusiva pertinenza di alcune persone. In questo modo l intero codice riceve le attenzioni di più programmatori, e risulta migliore e meno incline agli errori. La Collective Code Ownership potrebbe rappresentare un problema se le persone fossero costrette a lavorare alla cieca su codice che non conoscono. 40

RUP (Rational Unified Process)

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

Dettagli

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

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

Dettagli

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

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

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

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

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

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

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

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

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

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

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

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

Dettagli

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

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

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali Cos è un progetto? Un iniziativa temporanea intrapresa per creare un prodotto o un servizio univoco (PMI - Project Management

Dettagli

Corso Base ITIL V3 2008

Corso Base ITIL V3 2008 Corso Base ITIL V3 2008 PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it L informazione come risorsa strategica Nelle aziende moderne l informazione

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

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

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

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

Dettagli

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

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI CSC ritiene che la Business Intelligence sia un elemento strategico e fondamentale che, seguendo

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

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

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

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

Dettagli

Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking

Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking Seminario associazioni: Seminario a cura di itsmf Italia Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking Andrea Praitano Agenda Struttura dei processi ITIL v3; Il Problem

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

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

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

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

IT Service Management

IT Service Management IT Service Management ITIL: I concetti chiave ed il livello di adozione nelle aziende italiane Matteo De Angelis, itsmf Italia (I) 1 Chi è itsmf italia 12 th May 2011 - Bolzano itsmf (IT Service Management

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

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

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

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

Progettare, sviluppare e gestire seguendo la Think it easy philosophy

Progettare, sviluppare e gestire seguendo la Think it easy philosophy Progettare, sviluppare e gestire seguendo la Think it easy philosophy CST Consulting è una azienda di Consulenza IT, System Integration & Technology e Servizi alle Imprese di respiro internazionale. E

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

Metodologie di Analisi e Valutazione delle Posizioni e delle Prestazioni

Metodologie di Analisi e Valutazione delle Posizioni e delle Prestazioni HUMANWARE S.A.S. Via Tino Buazzelli, 51 00137 - Roma Tel.: +39 06 823861 Fax.:+39 06 233214866 Web: www.humanware.it Email: humanware@humanware.it Metodologie di Analisi e Valutazione delle Posizioni e

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

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

IT GOVERNANCE & MANAGEMENT

IT GOVERNANCE & MANAGEMENT IT GOVERNANCE & MANAGEMENT BOLOGNA BUSINESS school Dal 1088, studenti da tutto il mondo vengono a studiare a Bologna dove scienza, cultura e tecnologia si uniscono a valori, stile di vita, imprenditorialità.

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

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

Specialista ITIL. Certificate of Advanced Studies. www.supsi.ch/fc

Specialista ITIL. Certificate of Advanced Studies. www.supsi.ch/fc Scuola universitaria professionale della Svizzera italiana Dipartimento tecnologie innovative Istituto sistemi informativi e networking Specialista ITIL Certificate of Advanced Studies www.supsi.ch/fc

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

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

Dettagli

Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni. A cura di Bernardo Puccetti

Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni. A cura di Bernardo Puccetti Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni A cura di Bernardo Puccetti Il Business Process Management nella PA Presentazione SOFTLAB

Dettagli

1. QUAL È LO SCOPO DI QUESTO MODULO?

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

Dettagli

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

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

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

Dettagli

CenTer - SCHEDA DOCUMENTO

CenTer - SCHEDA DOCUMENTO CenTer - SCHEDA DOCUMENTO N 2467 TIPO DI DOCUMENTO: PROGRAMMA CORSO DI FORMAZIONE TIPOLOGIA CORSO: Corso universitario TIPO DI CORSO: Master di 1 Livello TITOLO: Gestione Integrata dei Patrimoni Immobiliari

Dettagli

Gli Standard hanno lo scopo di:

Gli Standard hanno lo scopo di: STANDARD INTERNAZIONALI PER LA PRATICA PROFESSIONALE DELL INTERNAL AUDITING (STANDARD) Introduzione agli Standard L attività di Internal audit è svolta in contesti giuridici e culturali diversi, all interno

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

LEAR ITALIA MES/LES PROJECT

LEAR ITALIA MES/LES PROJECT LEAR ITALIA MES/LES PROJECT La peculiarità del progetto realizzato in Lear Italia da Hermes Reply è quello di integrare in un unica soluzione l execution della produzione (con il supporto dell RFID), della

Dettagli

Comincio da tre! I MIEI AMICI LA MIA FAMIGLIA LE MIE ESPERIENZE IL MIO PASSATO COSA VOLEVO FARE DA GRANDE LE MIE RELAZIONI

Comincio da tre! I MIEI AMICI LA MIA FAMIGLIA LE MIE ESPERIENZE IL MIO PASSATO COSA VOLEVO FARE DA GRANDE LE MIE RELAZIONI I MIEI AMICI LA MIA FAMIGLIA IL MIO PASSATO LE MIE ESPERIENZE COSA VOLEVO FARE DA GRANDE COME SONO IO? I MIEI DIFETTI LE MIE RELAZIONI LE MIE PASSIONI I SOGNI NEL CASSETTO IL MIO CANE IL MIO GATTO Comincio

Dettagli

Energy risk management

Energy risk management Il sistema di supporto alle tue decisioni Energy risk management Un approccio orientato agli attori M.B.I. Srl, Via Francesco Squartini 7-56121 Pisa, Italia - tel. 050 3870888 - fax. 050 3870808 www.powerschedo.it

Dettagli

www.bistrategy.it In un momento di crisi perché scegliere di investire sulla Business Intelligence?

www.bistrategy.it In un momento di crisi perché scegliere di investire sulla Business Intelligence? In un momento di crisi perché scegliere di investire sulla Business Intelligence? Cos è? Per definizione, la Business Intelligence è: la trasformazione dei dati in INFORMAZIONI messe a supporto delle decisioni

Dettagli

Business Process Engineering (Ingegneria dei Processi Aziendali) L esperienza Engineering

Business Process Engineering (Ingegneria dei Processi Aziendali) L esperienza Engineering Business Process Engineering (Ingegneria dei Processi Aziendali) L esperienza Engineering Crema 14 dicembre 2010 Sergio Oltolina Senior Technical Manager Architetture e Consulenza Direzione Centrale Ricerca

Dettagli

SEZIONE F: DESCRIZIONE DELL'AZIONE. F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe):

SEZIONE F: DESCRIZIONE DELL'AZIONE. F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe): SEZIONE F: DESCRIZIONE DELL'AZIONE Project Management e Information Technology Infrastructure Library (ITIL V3 F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe):

Dettagli

L azienda e le funzioni aziendali

L azienda e le funzioni aziendali UDA 5 TEMA 3 L operatore impresa L azienda e le funzioni aziendali a cura di Lidia Sorrentino Il concetto di azienda. Per soddisfare i propri bisogni, fin dall antichità l uomo si è associato con altre

Dettagli

ELEMENTI DI TECNICA PROGETTUALE PER GLI INTERVENTI SOCIOSANITARI: INDICAZIONI PRATICHE PER LA STESURA DI UN PROGETTO

ELEMENTI DI TECNICA PROGETTUALE PER GLI INTERVENTI SOCIOSANITARI: INDICAZIONI PRATICHE PER LA STESURA DI UN PROGETTO ELEMENTI DI TECNICA PROGETTUALE ELEMENTI DI TECNICA PROGETTUALE PER GLI INTERVENTI SOCIOSANITARI: INDICAZIONI PRATICHE PER LA STESURA DI UN PROGETTO Giovanni Serpelloni 1), Elisabetta Simeoni 2) 1. Centro

Dettagli

Perché i progetti di Welfare falliscono? Falsi miti e azioni concrete per un welfare di successo

Perché i progetti di Welfare falliscono? Falsi miti e azioni concrete per un welfare di successo Perché i progetti di Welfare falliscono? Falsi miti e azioni concrete per un welfare di successo SOMMARIO Perché i progetti di Welfare falliscono? Falsi miti e azioni concrete per un welfare di successo

Dettagli

Schema Professionista della Security Profilo Senior Security Manager - III Livello

Schema Professionista della Security Profilo Senior Security Manager - III Livello STATO DELLE REVISIONI rev. n SINTESI DELLA MODIFICA DATA 0 05-05-2015 VERIFICA Direttore Qualità & Industrializzazione Maria Anzilotta APPROVAZIONE Direttore Generale Giampiero Belcredi rev. 0 del 2015-05-05

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

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

Legame fra manutenzione e sicurezza. La PAS 55

Legame fra manutenzione e sicurezza. La PAS 55 Gestione della Manutenzione e compliance con gli standard di sicurezza: evoluzione verso l Asset Management secondo le linee guida della PAS 55, introduzione della normativa ISO 55000 Legame fra manutenzione

Dettagli

Project Management Office per centrare tempi e costi

Project Management Office per centrare tempi e costi Project Management Office per centrare tempi e costi Il Project Management Office (PMO) rappresenta l insieme di attività e strumenti per mantenere efficacemente gli obiettivi di tempi, costi e qualità

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

Gara LOCO- Richiesta di chiarimenti

Gara LOCO- Richiesta di chiarimenti Domanda 1 Si chiede di specificare il numero orientativo dei partecipanti ai corsi di formazione diviso per tipologia (dirigenti, utenti e personale informatico) (cfr. Capitolato capitolo 10). Risposta

Dettagli

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA SAP World Tour 2007 - Milano 11-12 Luglio 2007 THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA Agenda Presentazione Derga Consulting Enterprise SOA Allineamento Processi & IT Il

Dettagli

ARTICOLO 61 MARZO/APRILE 2013 LA BUSINESS INTELLIGENCE 1. http://www.sinedi.com

ARTICOLO 61 MARZO/APRILE 2013 LA BUSINESS INTELLIGENCE 1. http://www.sinedi.com http://www.sinedi.com ARTICOLO 61 MARZO/APRILE 2013 LA BUSINESS INTELLIGENCE 1 L estrema competitività dei mercati e i rapidi e continui cambiamenti degli scenari in cui operano le imprese impongono ai

Dettagli

PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33

PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33 Settore Segreteria e Direzione generale Ufficio Trasparenza e Comunicazione PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33 Relazione anno 2014 a cura del Segretario Generale e della

Dettagli

CONCILIAZIONE FAMIGLIA & LAVORO IN IMPRESA

CONCILIAZIONE FAMIGLIA & LAVORO IN IMPRESA CONCILIAZIONE FAMIGLIA & LAVORO IN IMPRESA (Operazione 2011-796/PR - approvata con Delibera di Giunta Provinciale n. 608 del 01/12/2011) BANDO DI SELEZIONE DOCENTI E CONSULENTI La Provincia di Parma ha

Dettagli

DAL PROBLEMA AL PROGRAMMA

DAL PROBLEMA AL PROGRAMMA 1. I PROBLEMI E LA LORO SOLUZIONE DAL PROBLEMA AL PROGRAMMA L'uomo, per affrontare gli innumerevoli problemi postigli dallo sviluppo della civiltà, si è avvalso della scienza e della tecnica, i cui destini

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

Classificazioni dei sistemi di produzione

Classificazioni dei sistemi di produzione Classificazioni dei sistemi di produzione Sistemi di produzione 1 Premessa Sono possibili diverse modalità di classificazione dei sistemi di produzione. Esse dipendono dallo scopo per cui tale classificazione

Dettagli

PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA

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

Dettagli

IT Plant Solutions Soluzioni MES e IT per l Industria

IT Plant Solutions Soluzioni MES e IT per l Industria IT Plant Solutions IT Plant Solutions Soluzioni MES e IT per l Industria s Industrial Solutions and Services Your Success is Our Goal Soluzioni MES e IT per integrare e sincronizzare i processi Prendi

Dettagli

2.0 DAL WEB. social. tecnologico, 2006. Reply www.reply.eu

2.0 DAL WEB. social. tecnologico, 2006. Reply www.reply.eu ALL INTERNO DEL FIREWALL: ENI 2.0 Il modo di lavorare è soggetto a rapidi cambiamenti; pertanto le aziende che adottano nuovi tool che consentono uno scambio di informazioni contestuale, rapido e semplificato

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

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

PMI. Management Maturity Model, OPM3 Second Edition 2008

PMI. Management Maturity Model, OPM3 Second Edition 2008 Nuovi standard PMI, certificazioni professionali e non solo Milano, 20 marzo 2009 PMI Organizational Project Management Maturity Model, OPM3 Second Edition 2008 Andrea Caccamese, PMP Prince2 Practitioner

Dettagli

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

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

Dettagli

Capitolo 15 LE SCELTE DI ORGANIZZAZIONE. G. Airoldi, G. Brunetti, V. Coda Corso di economia aziendale Il Mulino, 2005

Capitolo 15 LE SCELTE DI ORGANIZZAZIONE. G. Airoldi, G. Brunetti, V. Coda Corso di economia aziendale Il Mulino, 2005 Capitolo 15 LE SCELTE DI ORGANIZZAZIONE G. Airoldi, G. Brunetti, V. Coda Corso di economia aziendale Il Mulino, 2005 1 L ASSETTO ORGANIZZATIVO, IL COMPORTAMENTO ORGANIZZATIVO In organizzazione il centro

Dettagli

PRESENTARE UN IDEA PROGETTUALE

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

Dettagli

SHORT MASTER: FROM ZERO TO HERO Dal project management al business modeling. settembre dicembre 2014 OBIETTIVI

SHORT MASTER: FROM ZERO TO HERO Dal project management al business modeling. settembre dicembre 2014 OBIETTIVI Organizzato da Impact Hub Rovereto in collaborazione con TrentunoTre con la supervisione scientifica di ISIPM SHORT MASTER: FROM ZERO TO HERO Dal project management al business modeling settembre dicembre

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

INTRODUZIONE 17. Introduzione

INTRODUZIONE 17. Introduzione INTRODUZIONE 17 Introduzione Questo libro nasce dal desiderio di raccogliere e condividere le idee elaborate dal nostro gruppo di lavoro nel corso della progettazione e realizzazione di progetti inerenti

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

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

ITIL Versione 3: un contributo all importanza crescente del Business Service Management

ITIL Versione 3: un contributo all importanza crescente del Business Service Management BEST PRACTICES WHITE PAPER ITIL Versione 3: un contributo all importanza crescente del Business Service Management Sharon Taylor, Presidente di Aspect Group, Chief Architect e Chief Examiner per ITIL Ken

Dettagli

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A2_3 V2.0. Processi. Scelta dei processi adeguati

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A2_3 V2.0. Processi. Scelta dei processi adeguati Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A2_3 V2.0 Processi Scelta dei processi adeguati Il contenuto del documento è liberamente utilizzabile dagli studenti,

Dettagli

IT Service Management: il Framework ITIL. Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy

IT Service Management: il Framework ITIL. Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy IT Service Management: il Framework ITIL Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy Quint Wellington Redwood 2007 Agenda Quint Wellington Redwood Italia IT Service Management

Dettagli

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE Roma, dicembre 1999 Analisi dei rischi in un progetto di sviluppo sw RISCHIO = potenziale difetto il cui verificarsi comporta dei danni Danno Non

Dettagli

1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS 20 Verona

1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS 20 Verona PRINCIPI PROJECT MANAGEMENT PRINCIPI DI PROJECT MANAGEMENT Elisabetta Simeoni 1), Giovanni Serpelloni 2) 1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS

Dettagli

L 8 maggio 2002 il Ministero

L 8 maggio 2002 il Ministero > > > > > Prima strategia: ascoltare le esigenze degli utenti, semplificare il linguaggio e la navigazione del sito. Seconda: sviluppare al nostro interno le competenze e le tecnologie per gestire in proprio

Dettagli

SAIPEM: Strong Authenticator for SAP Una soluzione CST in grado di garantire il massimo della sicurezza

SAIPEM: Strong Authenticator for SAP Una soluzione CST in grado di garantire il massimo della sicurezza Grandi Navi Veloci. Utilizzata con concessione dell autore. SAIPEM: Strong Authenticator for SAP Una soluzione CST in grado di garantire il massimo della sicurezza Partner Nome dell azienda SAIPEM Settore

Dettagli

Sussidio guida per la stesura della Relazione ex post

Sussidio guida per la stesura della Relazione ex post AGENZIA SANITARIA E SOCIALE REGIONALE ACCREDITAMENTO IL RESPONSABILE PIERLUIGI LA PORTA Sussidio guida per la stesura della Relazione ex post D.Lgs. 229/99 I principi introdotti dal DLgs 502/92 art. 8

Dettagli

+ / operatori di confronto (espressioni logiche/predicati) / + 5 3 9 = > < Pseudo codice. Pseudo codice

+ / operatori di confronto (espressioni logiche/predicati) / + 5 3 9 = > < Pseudo codice. Pseudo codice Pseudo codice Pseudo codice Paolo Bison Fondamenti di Informatica A.A. 2006/07 Università di Padova linguaggio testuale mix di linguaggio naturale ed elementi linguistici con sintassi ben definita e semantica

Dettagli

PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE

PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE (In vigore per le revisioni contabili dei bilanci relativi ai periodi amministrativi che iniziano

Dettagli

3. POLITICA, OBIETTIVI E ATTIVITA

3. POLITICA, OBIETTIVI E ATTIVITA Regione Siciliana Azienda Ospedaliera 17 3. POLITICA, OBIETTIVI E ATTIVITA 3.3 18 Le attività da svolgere per soddisfare i requisiti relativi alla politica, obiettivi ed attività consistono nella definizione:

Dettagli