I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo"

Transcript

1 Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2015 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano a buon fine. Martin Fowler 1 *** AVVERTENZA *** I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo 2

2 * Che cos è un processo software Un processo (o metodo) per lo sviluppo del software o, semplicemente, processo software definisce un approccio disciplinato per la costruzione, il rilascio e la manutenzione del software un processo definisce chi fa che cosa, quando e come per raggiungere un certo obiettivo che cosa sono le attività, chi sono i ruoli, come sono le metodologie, quando riguarda l organizzazione temporale delle attività Esistono numerosi processi software ad esempio, il processo a cascata, UP, Scrum, XP,... sono tutti organizzati attorno a un certo numero di attività fondamentali comuni 3 * Attività nei processi software Attività fondamentali comuni nei processi software specifica requisiti analisi comprensione/definizione di funzionalità e vincoli del software progettazione dell architettura e dei componenti implementazione validazione e verifica il software viene verificato per assicurare che faccia ciò che vuole il cliente rilascio/installazione manutenzione/evoluzione per soddisfare i requisiti del cliente che cambiano gestione del progetto 4

3 * Processi software Perché esistono diversi processi software? In cosa si differenziano? i diversi processi software non si differenziano nel che cosa i processi si differenziano soprattutto nel quando ovvero nel modo di determinare l ordine delle attività nello stabilire i criteri di transizione da una fase/attività alla successiva per quanto tempo continueremo a fare questa cosa? che cosa faremo dopo? e riguardo al chi? alcuni processi considerano ruoli specializzati altri processi considerano figure più complete, senza distinguere tra analista, progettista, programmatore e collaudatore e riguardo al come? molte metodologie per lo sviluppo del software possono essere usate in ogni processo altre sono più specifiche Che cos è UP Unified Process (UP) è un processo iterativo per lo sviluppo di software OO il contesto in cui si applica al meglio l OOA/D è proprio un processo iterativo applicato in modo agile 6 UP è aperto e flessibile e incoraggia l uso di pratiche da altri metodi iterativi come Scrum, Extreme Programming (XP), Agile Modeling ad es., sviluppo guidato dai test, refactoring, integrazione continua in questo modo, nel contesto di UP è possibile applicare le best practices ( pratiche migliori ) più comunemente accettate nello sviluppo del software in ogni caso, le idee fondamentali del corso (sviluppo iterativo, progettazione guidata dalle responsabilità, casi d uso, OOA/D, pattern,...) sono indipendenti da ogni particolare processo e possono essere applicate anche nel contesto di altri processi

4 Disclaimer Processi vs. Persone I principi, le tecnologie e i processi sono importanti ma sono le persone che li mettono in pratica [Cockburn] i processi e le tecnologie hanno un impatto secondario nei risultati di un progetto le persone con le loro individualità, sentimenti e qualità sono molto più importanti Le persone sono più importanti dei processi [Booch] persone buone che adottano un buon processo lavoreranno meglio, in ogni caso, di buone persone senza processo Per realizzare qualcosa di valore, le persone devono mettere anima e cuore in tutto quello che fanno i processi sono solo per migliorare il modo in cui le persone lavorano insieme Il processo a cascata Il processo a cascata è un processo software classico (definito tra gli anni 60 e 70 e ancora piuttosto diffuso) prevede uno svolgimento sequenziale di attività pianificazione con stime dettagliate per tutte le attività analisi dei requisiti del software progettazione generazione del codice collaudo inoltre ciascuna attività produce documenti dettagliati che sono soggetti a revisione e approvazione formale in accordo con il piano iniziale, il lavoro procede da un attività alla successiva solo con l approvazione dei documenti dell attività precedente spesso le diverse attività sono svolte da team differenti 8

5 2.3 Il processo a cascata Il processo a cascata è un processo software classico (definito tra gli anni 60 e 70 e ancora piuttosto diffuso) prevede uno svolgimento sequenziale di attività pianificazione con stime dettagliate per tutte le attività analisi dei requisiti del software progettazione generazione del codice Sequenziale vuole dire: collaudo prima faccio la pianificazione (mesi...) inoltre poi faccio tutta l analisi (altri mesi) ciascuna poi attività faccio produce tutta la documenti progettazione dettagliati (altri mesi) che sono soggetti poi a revisione scrivo il e codice approvazione (altri mesi) formale in accordo poi con inizio il piano a fare iniziale, il collaudo il lavoro (altri procede mesi) da un attività alla successiva a questo solo punto con ho l approvazione in mano qualcosa dei documenti di dell attività funzionante precedente (forse) spesso le diverse attività sono svolte da team differenti Il processo a cascata Il processo a cascata è un processo software classico (definito tra gli anni 60 e 70 e ancora piuttosto diffuso) prevede uno svolgimento sequenziale di attività Che pianificazione origini con ha? stime dettagliate per tutte le attività analisi dei requisiti del software progettazione Può generazione funzionare del codice per lo sviluppo del software? collaudo inoltre ciascuna attività produce documenti dettagliati che sono Potrebbe soggetti a revisione non e approvazione funzionare? formale in accordo con il piano iniziale, il lavoro procede da un attività In quali casi? Perché? alla successiva solo con l approvazione dei documenti Si dell attività può fare precedente di meglio? spesso le diverse attività sono svolte da team differenti 10

6 Il processo a cascata è poco efficace Il processo a cascata nella sua estrema logicità è spesso poco efficace nello sviluppo del software infatti è associato ad un elevata percentuale di fallimenti, a bassa produttività e a percentuali di difetti alte perché? Un motivo importante nello sviluppo a cascata è importante che tutte le buone idee sui requisiti, sull architettura, sul progetto vengano all inizio del progetto in modo che possano essere incorporate nel piano sappiamo che non è sempre così le buone idee possono venire in qualunque momento all inizio, a metà, e talvolta anche verso la fine di un progetto ma il processo a cascata non consente l introduzione di buone idee ritardatarie nel processo a cascata, una buona idea ritardataria non è un opportunità anzi, è una minaccia! 11 Il processo a cascata è poco efficace Un altro motivo il processo a cascata non consente una gestione efficace dei rischi in generale il processo a cascata affronta i rischi tardi nel ciclo di vita inoltre, è molto costoso gestire errori introdotti nelle prime fasi errori nei requisiti, nell analisi, nel progetto o anche nell implementazione Ad esempio, un ipotesi fondamentale del processo a cascata è che sia possibile definire correttamente e congelare i requisiti prima di procedere con le fasi successive ma questa ipotesi è realistica? 12

7 Il processo a cascata è poco efficace Studi empirici hanno dimostrato che in un progetto software medio i requisiti cambiano del 25% i cambiamenti sono del 35%-50% per progetti grandi e/o innovativi Cambiamento dei requisiti Dimensioni del progetto in Function Point la mancata gestione di questo cambiamento è una causa comune del fallimento dei progetti software 13 Requisiti che cambiano Un altra indagine se viene fatta un analisi a cascata dei requisiti, quante caratteristiche identificate inizialmente saranno effettivamente utili nel prodotto finale? Always 7% Often 13% Never 45% Sometimes 16% Rarely 19% 14

8 Il processo a cascata è poco efficace Molti praticanti del processo a cascata hanno sperimentato i suoi difetti più e più volte una possibile reazione è se solo lo avessimo applicato meglio, allora sì che avrebbe funzionato! più pianificazione, più documentazione maggior aderenza al piano, maggior resistenza ai cambiamenti ma la conseguenza di applicare meglio il processo a cascata è, di solito, un peggioramento dei risultati! Processo a cascata: si può fare di meglio? Lo sviluppo evolutivo e iterativo Nello sviluppo evolutivo l idea fondamentale è realizzare un implementazione iniziale del sistema, esporla agli utenti e raffinarla attraverso diverse versioni, finché non si ottiene un sistema adeguato l evoluzione del sistema è guidata da esperienze pratiche dell utilizzo del sistema il sistema viene esposto ai suoi utenti, ed evolve sulla base del feedback ottenuto dal suo utilizzo in pratica, per ottenere un feedback veloce ed efficace, le attività di specifica, sviluppo e verifica sono intrecciate anziché separate questo consente appunto un feedback veloce tra le varie attività 16

9 Lo sviluppo evolutivo e iterativo Nello sviluppo iterativo lo sviluppo del software è organizzato in una serie di mini-progetti brevi, di lunghezza fissa (ad es., 2-4 settimane) chiamati iterazioni ciascuna iterazione comprende lo svolgimento di attività di analisi dei requisiti, analisi, progettazione, implementazione, verifica il risultato di ciascuna iterazione è un sistema software eseguibile, integrato e testato, anche se parziale il sistema cresce in modo incrementale da un iterazione alla successiva adattandosi ai requisiti, in modo evolutivo, sulla base del feedback delle iterazioni precedenti il risultato di ciascuna iterazione è normalmente un sistema incompleto che converge verso un sistema completo dopo varie iterazioni 17 Sviluppo iterativo e incrementale 18

10 Sviluppo iterativo, incrementale ed evolutivo Sviluppo iterativo e incrementale il sistema cresce in modo incrementale, iterazione per iterazione Sviluppo iterativo ed evolutivo le specifiche e il progetto evolvono, in base a feedback ed adattamento 19 Cambiamento e adattamento Nello sviluppo del software, i cambiamenti sono inevitabili i cambiamenti sono combattuti nel processo a cascata, sequenziale i cambiamenti sono invece accettati dallo sviluppo iterativo lo sviluppo iterativo abbraccia il cambiamento e l adattamento, scegliendoli come guide essenziali ma non vuol dire lavorare in modo caotico ( feature creep ) Nello sviluppo iterativo, ciascuna iterazione opera su un piccolo sottoinsieme dei requisiti analisi, progettazione, implementazione e verifica fornisce un ritorno (feedback) rapido dagli utenti, dagli sviluppatori e dal test questo ritorno è un opportunità per far crescere il sistema, riducendo i rischi 20

11 Cambiamento e adattamento Nello sviluppo del software, i cambiamenti sono inevitabili i cambiamenti sono combattuti nel processo a cascata, sequenziale L idea di fondo dello sviluppo i cambiamenti sono invece accettati dallo sviluppo iterativo iterativo: lo sviluppo iterativo anticipare abbraccia nel il cambiamento tempo parte e di l adattamento, alcune attività, scegliendoli rimandare come guide essenziali nel ma non vuol dire lavorare in modo caotico ( feature creep ) tempo parte di altre attività, cercando di massimizzare i Nello sviluppo iterativo, ciascuna iterazione opera su un piccolo sottoinsieme dei requisiti benefici analisi, progettazione, e di minimizzare implementazione i e rischi verifica fornisce un ritorno (feedback) rapido dagli utenti, dagli sviluppatori e dal test questo ritorno è un opportunità per far crescere il sistema, riducendo i rischi 21 Cambiamento e adattamento Nello sviluppo del software, i cambiamenti sono inevitabili i in cambiamenti particolare, produrre sono combattuti nel processo ad esempio, a cascata, la codice ed esporlo ai sequenziale comprensione di L idea clienti di fondo dello sviluppo requisiti meno i cambiamenti sono invece accettati dallo sviluppo importanti iterativo iterativo: lo sviluppo iterativo anticipare abbraccia nel il cambiamento tempo parte e l adattamento, scegliendoli come guide essenziali di alcune attività, rimandare nel tempo parte di altre attività, cercando di massimizzare i benefici e di minimizzare i rischi ma non vuol dire lavorare in modo caotico ( feature creep ) Nello sviluppo iterativo, ciascuna iterazione opera su un piccolo sottoinsieme dei requisiti analisi, progettazione, implementazione e verifica fornisce un ritorno (feedback) rapido non posso procedere a dagli utenti, dagli caso, sviluppatori la pianificazione e dal test questo ritorno è un opportunità è importante per far crescere il sistema, riducendo i rischi 22

12 Cambiamento e adattamento 23 Vantaggi dello sviluppo iterativo Vantaggi dello sviluppo iterativo dimostrati da ricerche sullo sviluppo iterativo e incrementale minor probabilità di fallimento del progetto, miglior produttività, percentuali più basse di difetti riduzione precoce anziché tardiva dei rischi maggiori visibilità del progresso feedback precoce, impegno degli utenti, adattamento gestione della complessità miglioramento continuo del processo stesso Attenzione: ci sono anche dei rischi ma conoscendoli è possibile affrontarli in modo opportuno 24

13 Progetti iterativi vs. pensare a cascata Un rischio comune dire di adottare un processo iterativo ma in realtà pensare a cascata in questa iterazione scrivo i requisiti in questa iterazione faccio il progetto solo dopo scrivo il codice il test lo faccio in un altra iterazione purtroppo visto anche in molti tirocini e tesi In questo caso il pensiero a cascata ha inficiato il progetto non si tratta di un progetto iterativo o UP sano 25 Timeboxing Ciascuna iterazione ha una durata prefissata di circa una-sei settimane, a seconda dello specifico processo iterazioni brevi consentono un adeguato feedback e adattamento ai cambiamenti le iterazioni troppo brevi, invece, non consentono di svolgere lavoro sufficiente in un iterazione le iterazioni troppo lunghe, invece, non consentono di ottenere completamente i benefici dello sviluppo iterativo, aumentando così i rischi la durata di un iterazione, una volta fissata, non può cambiare le iterazioni sono timeboxed ciascuna iterazione deve produrre un sistema eseguibile (anche se parziale) è meglio ridurre i requisiti di un iterazione, piuttosto che non rispettarne la scadenza 26

14 * Iterazioni e requisiti bloccati Durante ciascuna iterazione, i requisiti su cui operare vengono prefissati (ovvero, stabiliti all inizio dell iterazione) e bloccati (non possono cambiare durante l iterazione) il team di sviluppo, nell ambito di ciascuna iterazione, può lavorare al suo meglio, concentrandosi solo sul lavoro richiesto dall iterazione poiché i requisiti sono bloccati, il team non può essere interrotto o disturbato dai committenti durante un iterazione, con un impatto decisamente positivo sulla tranquillità del team e sulla possibilità di raggiungere gli obiettivi di sviluppo dell iterazione in ogni caso, al termine di ciascuna iterazione i committenti possono vedere il progresso effettivo dello sviluppo, e fornire un feedback per guidare lo sviluppo successivo poiché le iterazioni sono brevi, il progresso e il feedback sono frequenti inoltre, nuove richieste dei committenti potranno essere prese in considerazione nelle iterazioni successive ma non è un grosso problema, perché le iterazioni sono brevi 27 * Backlog e pianificazione iterativa Il backlog ( lavoro arretrato ) è uno strumento per l organizzazione del lavoro che deve essere ancora svolto nello sviluppo iterativo il backlog è un elenco di requisiti che devono essere ancora implementati e di problemi che devono essere ancora risolti la gestione del backlog è iterativa e guida la pianificazione e l evoluzione del processo di sviluppo prima di iniziare una nuova iterazione le voci del backlog vengono aggiornate facendo cancellazioni, aggiunte o modifiche anche sulla base del feedback dell iterazione che si sta concludendo a ciascuna voce viene assegnata una priorità sulla base del valore di business e dei rischi associati a quella voce per l iterazione che sta per iniziare viene scelto come compito l implementazione di voci del lavoro arretrato tra quelle che hanno priorità maggiore 28

15 2.4 OOA/D iterativa ed evolutiva Si immagini che questo progetto sia costituito da 20 iterazioni. Nello sviluppo iterativo ed evolutivo, i requisiti evolvono durante le prime iterazioni, per esempio attraverso una serie di workshop sui requisiti. Dopo forse quattro iterazioni e workshop, il 90% dei requisiti è stato definito e raffinato. Ciononostante, è stato costruito solo il 10% del software OOA/D iterativa ed evolutiva workshop sui requisiti Si immagini che questo progetto sia costituito da 20 iterazioni. Nello sviluppo iterativo ed evolutivo, i requisiti evolvono durante le prime iterazioni, per esempio attraverso una serie di workshop sui requisiti. Dopo forse quattro iterazioni e workshop, il 90% dei requisiti è stato definito e raffinato. Ciononostante, è stato costruito solo il 10% del software. requisiti software requisiti software 90% 90% 50% 20% 30% 2% 5% 8% 10% 20% Iterazione 1 Iterazione 2 Iterazione 3 Iterazione 4 Iterazione 5 30

16 2.4 OOA/D iterativa ed evolutiva workshop sui requisiti Si immagini che questo progetto sia costituito da 20 iterazioni. Nello sviluppo iterativo ed evolutivo, i requisiti evolvono durante le prime iterazioni, per esempio attraverso una serie di workshop sui requisiti. Dopo forse quattro iterazioni e workshop, il 90% dei requisiti è stato definito e raffinato. Ciononostante, è stato costruito solo il 10% del software. requisiti 20% software 2% requisiti 30% software 5% 50% Iterazione 1 Iterazione 2 Iterazione 3 Iterazione 4 Iterazione 5 un iterazione di 3 settimane 8% 90% 90% 10% 20% settimana 1 Lun Mar Mer Gio Ven settimana 2 Lun Mar Mer Gio Ven settimana 3 Lun Mar Mer Gio Ven riunione di avvio che chiarisce gli obiettivi dell iterazione con il team (1 ora) modellazione agile & progettazione usando UML come abbozzo alla lavagna (5 ore) inizio codifica & test Molta OOA/D e applicazione di UML in questo periodo la portata degli obiettivi dell iterazione viene ridotta se il lavoro è eccessivo check-in finale e congelamento del codice per la baseline dell iterazione Modellazione dei casi d uso durante il workshop workshop per demo e requisiti (2 giorni) riunione per la pianificazione della prossima iterazione (2 ore) 31 * Parentesi: Principio di Pareto Principio di Pareto la maggior parte degli effetti è dovuta a un numero ristretto di cause Una legge empirica detta anche legge 80/20 la maggior parte degli effetti (ad es., l 80%) è dovuta a un numero ristretto di cause (ad es., il 20%) i valori 80% e 20% sono solo indicativi applicazioni economia, informatica, qualità,... Quale interpretazione della figura precedente? le prime iterazioni si possono occupare solo del 20% dei requisiti o del sistema ma non si devono occupare di un 20% a caso ma proprio del 20% dei requisiti o del sistema che contribuiscono all 80% del valore complessivo! 32

17 2.5 Pianificazione iterativa Una pratica fondamentale dello sviluppo iterativo è la pianificazione iterativa che cosa fare nella prossima iterazione? UP incoraggia la pianificazione iterativa guidata dal rischio e guidata dal cliente obiettivo delle prime iterazioni identificare e affrontare i rischi principali implementare caratteristiche visibili a cui il cliente è particolarmente interessato compatibile con la pratica dello sviluppo centrato sull architettura le prime iterazioni si concentrano sulla costruzione, il test e la stabilizzazione del nucleo dell architettura 33 * Sviluppo iterativo e qualità del codice L adozione di un processo di sviluppo iterativo impone alcune qualità che il software deve possedere in particolare, la struttura del software deve essere flessibile, in modo tale che l impatto dei cambiamenti sul sistema sia basso a tal fine, il codice ma anche il progetto sottostante deve essere facilmente modificabile inoltre, come prerequisito, il codice ma anche il progetto sottostante deve essere facilmente comprensibile Attenzione, queste osservazioni apparentemente banali hanno un impatto fondamentale sul modo di fare analisi e progettazione del software 34

18 * Sviluppo iterativo e qualità del codice L adozione di un processo di sviluppo iterativo impone alcune qualità che il software deve possedere in particolare, la struttura del software deve essere flessibile, in modo tale che l impatto dei cambiamenti sul sistema sia basso a tal fine, il codice ma anche il progetto sottostante deve essere facilmente modificabile inoltre, come prerequisito, il codice ma anche il progetto sottostante deve essere facilmente comprensibile Come sostenere queste qualità? applicando principi di progettazione opportuni salto rappresentazionale basso, modularità, separazione degli interessi,... utilizzando strumenti (metodologici) opportuni tecnologie OO, refactoring, sviluppo guidato dai test, tracciatura dei requisiti e gestione delle modifiche, pianificazione iterativa, Sviluppo agile Lo sviluppo agile incoraggia l adozione di valori e pratiche che incoraggiano una reazione rapida e flessibile ai cambiamenti (agilità) semplicità, leggerezza, valore delle persone, comunicazione,... sviluppo iterativo e incrementale, pianificazione adattiva,... programmazione a coppie, sviluppo guidato dai test, refactoring,... Agilità si contrappone a pesantezza (burocratizzazione del lavoro) predittività I processi iterativi (UP compreso) possono essere applicati in modo agile 36

19 Manifesto e principi agili Sono più importanti gli individui e le interazioni il software funzionante la collaborazione con il cliente rispondere al cambiamento più che i processi e gli strumenti più che la documentazione esaustiva più che la negoziazione dei contratti più che seguire un piano La principale priorità è soddisfare il cliente con la consegna continua e frequente di software di valore Il cambiamento dei requisiti per il vantaggio competitivo del cliente è benvenuto Gli sviluppatori e i clienti devono lavorare insieme quotidianamente Costruire il progetto attorno a persone motivate Il modo più efficiente ed efficace di fornire informazioni è la comunicazione faccia a faccia La misura principale del progresso è il software funzionante Sviluppo sostenibile Attenzione alla perfezione tecnica e alla buona progettazione Semplicità Gruppi di lavoro auto-organizzati, che migliorano in modo iterativo Agile Modeling Il segreto della modellazione lo scopo principale della modellazione non è documentare ma piuttosto è quello di comprendere e di favorire la comunicazione 38

20 Agile Modeling Principi e valori dell Agile Modeling adottare un metodo agile non significa evitare del tutto la modellazione anche XP accetta la modellazione purché agile lo scopo dei modelli e della modellazione è agevolare la comprensione e la comunicazione non modellare tutto usa gli strumenti più semplici possibili non modellare da solo crea modelli in parallelo itera a un altro elaborato tenere presente che tutti i modelli saranno incompleti e imprecisi 39 Es: Usa gli strumenti più semplici possibili 40

21 2.8 Che cos è UP agile UP comprende un vasto insieme di ruoli, elaborati, attività e flussi di lavoro molti elementi sono opzionali personalizzazione di UP UP può essere applicato in modo agile UP agile un piccolo insieme di attività ed elaborati requisiti, analisi e progettazione iterativa e adattiva applicazione di UML secondo lo spirito della modellazione agile pianificazione iterativa e adattiva Altre pratiche fondamentali di UP UP promuove diverse discipline fondamentali (best practices) sviluppare software in modo iterativo, evolutivo ed adattivo sviluppo guidato dal rischio sviluppare il cuore dell architettura nelle prime iterazioni coinvolgimento continuo degli utenti verifica continua delle qualità testare presto, spesso, e in modo realistico applicare i casi d uso se appropriato modellare in modo visuale gestire attentamente i requisiti gestire le richieste di cambiamento e le configurazioni uso delle tecnologie a oggetti (OOA/OOD/OOP) sviluppo basato su componenti 42

22 2.10 Fasi di UP Un progetto UP organizza il lavoro e le iterazioni in quattro fasi principali ideazione (inception) avvia il progetto visione approssimativa del sistema, stime vaghe dei costi elaborazione (elaboration) realizza il nucleo dell architettura visione raffinata del sistema, implementazione iterativa del nucleo dell architettura, risoluzione dei rischi maggiori, identificazione della maggior parte dei requisiti, stime realistiche dei costi costruzione (construction) realizza le capacità operative iniziali implementazione iterativa, risoluzione dei rischi minori transizione (transition) completa il prodotto verifiche finali (beta test) e rilascio agli utenti 43 Fasi di un progetto UP ciclo di sviluppo iterazione fase ideaz. elaborazione costruzione transizione milestone La fine di un iterazione in cui si verifica una decisione o una valutazione significativa. release Un sottoinsieme stabile ed eseguibile del prodotto finale. La fine di ogni iterazione produce una release minore. incremento La differenza (delta) tra le release di due iterazioni successive. release produzione finale A questo punto il sistema viene rilasciato e consegnato ai clienti. 44

23 2.11 Discipline di UP In UP, le attività lavorative (compiti) sono organizzate in discipline una disciplina è l insieme delle attività, e dei relativi elaborati, relative a una determinata area un elaborato (artifact) è il termine generico che indica un prodotto di lavoro Tra le discipline di UP, tre sono di interesse per questo corso requisiti modellazione del business (business modeling) progettazione Alcune ulteriori discipline di UP implementazione test gestione del progetto 45 Discipline di UP e sviluppo iterativo Interesse di questo libro Alcune discipline di UP Modellazione del Business Requisiti Progettazione Implementazione Test Rilascio Un iterazione di quattro settimane (per esempio). Un mini-progetto che comprende lavoro nella maggior parte delle discipline, che termina con un prodotto eseguibile stabile. Si noti che, nonostante l iterazione includa lavoro nella maggior parte delle discipline, l impegno relativo e l enfasi cambiano nel tempo. Questo esempio è solo un suggerimento, non è da prendere alla lettera. Gestione delle Configurazioni e delle Modifiche Gestione del Progetto Infrastruttura Iterazioni 46

24 Discipline di UP e sviluppo iterativo La figura mostra che ciascuna iterazione coinvolge molte o tutte le discipline lo sforzo richiesto da ciascuna disciplina cambia durante lo svolgimento delle varie fasi e iterazioni 47 Struttura del corso, fasi e discipline Questo corso enfatizza soprattutto la fase di elaborazione alcune attività ed elaborati delle discipline di modellazione del business, requisiti, progettazione che sono la fase e le discipline in cui vengono principalmente applicate l analisi dei requisiti, l OOA, l OOD, i pattern, UML Overview Inception Elaboration Iteration 1 Elaboration Iteration 2 Elaboration Iteration 3 Special Topics Object-Oriented Analysis Object-Oriented Design Translating Designs to Code Topics such as OO analysis and OO design are incrementally introduced in iteration 1, 2, and 3. 48

25 2.12 Personalizzare UP Alcuni principi e pratiche di UP sono indispensabili ad eccezione del codice, tutte le attività e gli elaborati sono opzionali ciascun progetto va basato sugli elaborati e le attività che sono effettivamente di valore per quel particolare progetto La scelta degli elaborati di UP per un progetto viene scritta in un breve documento lo Scenario di sviluppo (development case) disciplina di infrastruttura (environment) 49 Scenario di sviluppo per lo studio di caso Disciplina Pratiche Elaborato Modellazione del business Requisiti Progettazione Implementazione Gestione del progetto... agile modeling workshop requisiti workshop requisiti vision box dot voting agile modeling test-driven dev. test-driven dev. pair programming integrazione continua standard di codifica agile PM daily meeting Modello di dominio (Domain Model) s = start (inizia) r = refine (raffina) Ideaz. (I1) Elab. (E1..En) s Costr. (C1..Cn) Modello dei casi d'uso (Use-Case Model) s r Visione (Vision) s r Specifiche supplementari (Supplementary Specification) s r Glossario (Glossary) s r Modello di progetto (Design Model) s r Documento dell'architettura software (SW Architecture Document, SAD) s Modello dei dati (Data Model) s r Modello di implementazione (Implementation Model) Piano di sviluppo software (SW Development Plan) Trans. (T1..T2) s r r s r r r 50

26 2.13 Non hai capito lo sviluppo iterativo o UP se pensi che ideazione=requisiti, elaborazione=progettazione e costruzione=implementazione pensi che lo scopo dell elaborazione è di definire modelli, che vengono implementati (in codice) nella fase di costruzione provi a definire la maggior parte dei requisiti prima di iniziare la progettazione e l implementazione provi a fare la maggior parte della progettazione prima di iniziare l implementazione provi a definire e scegliere una architettura prima di iniziare la programmazione e il test in modo iterativo viene speso molto tempo per i requisiti e la progettazione prima di iniziare la programmazione credi che la lunghezza giusta per le iterazioni sia tre mesi non tre settimane pensi che la creazione di diagrammi UML e le attività di progettazione devono definire il progetto in dettaglio, e che la programmazione è semplicemente traduzione di questi diagrammi pensi che adottare UP significhi svolgere quante più attività e produrre quanti più elaborati possibili provi a pianificare il progetto in dettaglio dall inizio alla fine, in modo speculativo vuoi piani e stime dei costi credibili prima che sia conclusa la fase di elaborazione 51

* Che cos è un processo software

* Che cos è un processo software Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2013 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

Dettagli

4.1 Che cos è l ideazione

4.1 Che cos è l ideazione Luca Cabibbo Analisi e Progettazione del Software Ideazione (non è la fase dei requisiti) Capitolo 4 marzo 2013 Il meglio è nemico del bene. Voltaire 1 *** AVVERTENZA *** I lucidi messi a disposizione

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

UML e (R)UP (an overview)

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

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

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

Dettagli

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

Sviluppo iterativo ed evolutivo

Sviluppo iterativo ed evolutivo Luca Cabibbo Analisi e Progettazione del Software Capitolo 2 marzo 2017 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera vadano a buon fine. Martin Fowler 1 2.2 Processi

Dettagli

7.1 Livello di completezza degli esempi

7.1 Livello di completezza degli esempi Luca Cabibbo Analisi e Progettazione del Software Capitolo 7 marzo 2013 Buono, poco costoso, rapidamente. Puoi scegliere due di queste caratteristiche. Anonimo 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti Sviluppo Agile [Cockburn 2002] Extreme Programming (XP) [Beck 2000] Sono più importanti auto-organizzazione, collaborazione, comunicazione tra membri del team e adattabilità del prodotto rispetto ad ordine

Dettagli

13. Ciclo di Vita e Processi di Sviluppo

13. Ciclo di Vita e Processi di Sviluppo 13. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 13. Ciclo di Vita e Processi

Dettagli

RUP (Rational Unified Process)

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

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1 Scrum Caratteristiche, Punti di forza, Limiti versione del tutorial: 1.0 Pag. 1 Scrum è uno dei processi agili (www.agilealliance.com) il termine è derivato dal Rugby, dove viene chiamato Scrum il pacchetto

Dettagli

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica.

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica. Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite Agile Group DIEE, Università di Cagliari www.agile.diee.unica.it Agile Group Agile Group, gruppo di ricerca su Ingegneria del SW,

Dettagli

Analisi e progettazione del software

Analisi e progettazione del software Luca Cabibbo Analisi e Progettazione del Software Analisi e progettazione del software Introduzione al corso marzo 2015 Qualcuno me l ha mostrato, e io l ho trovato da solo. Detto Zen 1 Analisi e progettazione

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

Gestione di progetti (software)

Gestione di progetti (software) Gestione di progetti (software) Tecniche di Programmazione Lez. 03 Università di Firenze a.a. 2009/10, I semestre 1/25 Contenuti Gestione di progetto Ruoli professionali Pianificazione di progetto Stima

Dettagli

Modellazione di sistema

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

Dettagli

Analisi e progettazione del software

Analisi e progettazione del software Luca Cabibbo Analisi e Progettazione del Software Analisi e progettazione del software L esperienza non è quello che ti succede, Introduzione al corso ma quello che te ne fai marzo 2013 di quello che ti

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

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

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

Dettagli

Cambiare il Sistema Informativo

Cambiare il Sistema Informativo Cambiare il Sistema Informativo avvertenze e consigli per la partenza ex-novo o per la sostituzione di quello esistente Febbraio 2008 1 Contenuti Premessa Caratteristiche di un buon Sistema Informativo

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software. Gestione di progetto. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software. Gestione di progetto. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del Gestione di progetto Contenuti Gestione di progetto Ruoli professionali Pianificazione di progetto Stima dei costi di progetto Rischi

Dettagli

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

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

Dettagli

SISTEMA E-LEARNING INeOUT

SISTEMA E-LEARNING INeOUT SISTEMA E-LEARNING INeOUT AMBIENTE OPERATIVO 1 Premesse metodologiche La complessità di un sistema informatico dipende dall aumento esponenziale degli stati possibili della sua architettura. Se è vero

Dettagli

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 15: P.M.: metodologie di progetto Prof.ssa R. Folgieri email: folgieri@dico.unimi.it folgieri@mtcube.com 1 Modelli di conduzione

Dettagli

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo Luca Cabibbo Analisi e Progettazione del Software Capitolo 3 marzo 2015 Poche cose sono più difficili da sopportare di un buon esempio. Mark Twain 1 *** AVVERTENZA *** I lucidi messi a disposizione sul

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

Teeled S.r.l. PRESENTAZIONE DELLA SOCIETÀ

Teeled S.r.l. PRESENTAZIONE DELLA SOCIETÀ Teeled S.r.l. PRESENTAZIONE DELLA SOCIETÀ Teeled S.r.l. - Sede in Rapallo (GE), Corso Italia n.36/6 C.F. e P.IVA: 01931930992 - Capitale sociale: 10.000,00 - Iscritta presso la C.C.I.A.A. di Genova - R.E.A.446248

Dettagli

Che cos è un prototipo? Prototipazione. Perchè creare prototipi? Insidie. I processi corrono in parallelo

Che cos è un prototipo? Prototipazione. Perchè creare prototipi? Insidie. I processi corrono in parallelo Che cos è un? Prototipazione Un modello approssimato o parziale del sistema che vogliamo sviluppare che simula o esegue alcune funzioni del sistema finale, realizzato allo scopo di valutarne le caratteristiche

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

Dettagli

Coordinamento e comunicazione

Coordinamento e comunicazione Team Agili I membri del team devono fidarsi gli uni degli altri. Le competenze dei membri del team deve essere appropriata al problema. Evitare tutte le tossine che creano problemi Il team si organizza

Dettagli

Ingegneria del Software Requisiti e Specifiche

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

Dettagli

PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio Lean IT

PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio Lean IT CDC -Corte dei conti DGSIA Direzione Generale Sistemi Informativi Automatizzati SGCUS Servizio per la gestione del Centro Unico dei Servizi PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio

Dettagli

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi Project Management Modulo: Introduzione prof. ing. Guido Guizzi Definizione di Project Management Processo unico consistente in un insieme di attività coordinate con scadenze iniziali e finali, intraprese

Dettagli

Sviluppo di applicazioni internet:

Sviluppo di applicazioni internet: Sviluppo di applicazioni internet: Rad versus approccio formale Mario Quirico 2 Come si fa a introdurre l'uso di tecniche formali nello sviluppo delle applicazioni internet senza incappare nelle spire

Dettagli

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

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

Dettagli

Verifica e Validazione del Simulatore

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

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi Un team agile allo sprint 28 Febbraio 2013 Emiliano Soldi una questione di leggerezza COMPLESSITÀ VARIABILITÀ SPRECHI SOVRA-ALLOCAZIONI COLLI DI BOTTIGLIA DEBITO BUSINESS/TECNICO RIDURRE TEMPI ATTESA RIDURRE

Dettagli

11. Evoluzione del Software

11. Evoluzione del Software 11. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 11. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

Ciclo di Vita Evolutivo

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

Dettagli

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

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA Service Oriented Architecture Ormai tutti, nel mondo dell IT, conoscono i principi di SOA e i benefici che si possono ottenere

Dettagli

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo Luca Cabibbo Analisi e Progettazione del Software Capitolo 3 marzo 2016 Agilità:1, ogni altra cosa: 0. Tom DeMarco 1 *** AVVERTENZA *** I lucidi messi a disposizione sul sito del corso di Analisi e progettazione

Dettagli

Principi dell ingegneria del software Relazioni fra

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

Dettagli

Il marketing dei servizi

Il marketing dei servizi Il marketing dei servizi Il gap 2: la progettazione del servizio e gli standard operativi visibili e misurabili dai clienti 22 P f ROBERTO PAPA GAP 2: il gap di progettazione del servizio Il secondo gap

Dettagli

figure professionali software

figure professionali software Responsabilità del Program Manager Valuta la fattibilità tecnica delle opportunità di mercato connesse al programma; organizza la realizzazione del software in forma di progetti ed accorpa più progetti

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

Project Management. Corso Sistemi Informativi Aziendali, Tecnologie dell Informazione applicate ai processi aziendali.

Project Management. Corso Sistemi Informativi Aziendali, Tecnologie dell Informazione applicate ai processi aziendali. Corso Sistemi Informativi Aziendali, Project Management. di Simone Cavalli (simone.cavalli@unibg.it) Bergamo, Maggio 2010 Project Management: definizioni Progetto: Progetto si definisce, di regola, uno

Dettagli

Le Dimensioni della LEADERSHIP

Le Dimensioni della LEADERSHIP Le Dimensioni della LEADERSHIP Profilo leadership, dicembre 2007 Pag. 1 di 5 1. STRATEGIA & DIREZIONE Creare una direzione strategica Definire una strategia chiara e strutturata per la propria area di

Dettagli

12. Evoluzione del Software

12. Evoluzione del Software 12. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 12. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE Relatore: prof. Michele Moro Laureando: Marco Beggio Corso di laurea in Ingegneria Informatica Anno Accademico 2006-2007

Dettagli

Processi principali per il completamento del progetto

Processi principali per il completamento del progetto Piano di progetto È un documento versionato, redatto dal project manager per poter stimare realisticamente le risorse, i costi e i tempi necessari alla realizzazione del progetto. Il piano di progetto

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

Ingegneria del Software. Processi di Sviluppo

Ingegneria del Software. Processi di Sviluppo Ingegneria del Software Processi di Sviluppo Ingegneria del Software: Tecnologia Stratificata tools metodi processi Focus sulla qualità Ingegneria del Software: Tecnologia Stratificata (2) Qualità Elemento

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

5. Requisiti del Software II

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

Dettagli

WebRatio. Per il settore Energy e Utilities. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7

WebRatio. Per il settore Energy e Utilities. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7 WebRatio Per il settore Energy e Utilities Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7 Il divario tra Business e IT nel settore Energy e Utilities Il settore Energy e Utilities è in grande

Dettagli

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ SERVIZI DI PROJECT MANAGEMENT CENTRATE I VOSTRI OBIETTIVI LA MISSIONE In qualità di clienti Rockwell Automation, potete contare

Dettagli

La portata del software

La portata del software La portata del software Portata Contesto. In che modo il software in costruzione si inserirà nel sistema, prodotto o contesto aziendale esistente e quali vincoli impone il contesto? Obiettivi relativi

Dettagli

GESTIONE DEI PROGETTI. Inizio

GESTIONE DEI PROGETTI. Inizio GESTIONE DEI PROGETTI Problema del management Fallimento negli anni 60, inizio 70 Non tanto dovuto alla competenza Un buon management non garantisce il successo ma un cattivo management risulta spesso

Dettagli

Norme per l organizzazione - ISO serie 9000

Norme per l organizzazione - ISO serie 9000 Norme per l organizzazione - ISO serie 9000 Le norme cosiddette organizzative definiscono le caratteristiche ed i requisiti che sono stati definiti come necessari e qualificanti per le organizzazioni al

Dettagli

FORNITORE: SEDE: TELEFONO FAX INDICAZIONI PER LA COMPILAZIONE DEL QUESTIONARIO

FORNITORE: SEDE: TELEFONO FAX INDICAZIONI PER LA COMPILAZIONE DEL QUESTIONARIO FORNITORE: SEDE: TELEFONO FAX INDICAZIONI PER LA COMPILAZIONE DEL QUESTIONARIO L autovalutazione è una valutazione che fornisce un giudizio sull efficacia e sull efficienza dell Azienda e sul grado di

Dettagli

LA PIANIFICAZIONE DELLE ATTIVITÀ AZIENDALI E.R.P. (ENTERPRISE RESOURCE PLANNING)

LA PIANIFICAZIONE DELLE ATTIVITÀ AZIENDALI E.R.P. (ENTERPRISE RESOURCE PLANNING) LA PIANIFICAZIONE DELLE ATTIVITÀ AZIENDALI E.R.P. (ENTERPRISE RESOURCE PLANNING) L IMPATTO SULLA GESTIONE LA MISURAZIONE DELL IMPATTO IL SUPPORTO ALLA CREAZIONE DEL VALORE L INTEGRAZIONE ESIGENZE DEL BUSINESS

Dettagli

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a

Dettagli

ARTICOLO TECNICO Smart-MED-Parks: il Software

ARTICOLO TECNICO Smart-MED-Parks: il Software ARTICOLO TECNICO Smart-MED-Parks: il Software Introduzione Da Febbraio 2013, data di lancio del progetto Smart-MED-Parks, sono state realizzate un insieme di azioni al fine di: - Aumentare il livello di

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si è compreso che il processo andava formalizzato attraverso: un insieme

Dettagli

1. STRUTTURA INFORMATICA GENERALE

1. STRUTTURA INFORMATICA GENERALE Come operare il controllo di gestione Per essere competitivi è necessario controllare sia i costi dell azienda, sia la gestione finanziaria, di un reparto come di una divisione. Un efficiente sistema di

Dettagli

Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna. SKF Car Business Unit

Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna. SKF Car Business Unit Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna 1 Un approccio difficile perchè Il Team conta più del singolo Utilizza risorse condivise E trasversale

Dettagli

La Gestione delle Risorse Umane nello Studio Professionale. Dott. Simone Cavestro Sinthema Professionisti Associati

La Gestione delle Risorse Umane nello Studio Professionale. Dott. Simone Cavestro Sinthema Professionisti Associati La Gestione delle Risorse Umane nello Studio Professionale Dott. Simone Cavestro La Sfida attuale In uno scenario in continua evoluzione, dove si sviluppano con velocità crescente Organizzazione Tecnologie

Dettagli

I Sistemi Gestione Energia e il ruolo dell energy manager

I Sistemi Gestione Energia e il ruolo dell energy manager I Sistemi Gestione Energia e il ruolo dell energy manager Valentina Bini, FIRE 27 marzo, Napoli 1 Cos è la FIRE La Federazione Italiana per l uso Razionale dell Energia è un associazione tecnico-scientifica

Dettagli

Principio 1 Organizzazione orientata al cliente. Principio 2 Leadership. Principio 3 - Coinvolgimento del personale

Principio 1 Organizzazione orientata al cliente. Principio 2 Leadership. Principio 3 - Coinvolgimento del personale Gli otto princìpi di gestione per la qualità possono fornire ai vertici aziendali una guida per migliorare le prestazioni della propria organizzazione. Questi princìpi, che nascono da esperienze collettive

Dettagli

IL LAVORO CON I DSA NELLA CLINICA E NELLA SCUOLA: COMPITI ED OBIETTIVI DI CIASCUNO MULTIDISCIPLINARE

IL LAVORO CON I DSA NELLA CLINICA E NELLA SCUOLA: COMPITI ED OBIETTIVI DI CIASCUNO MULTIDISCIPLINARE I Bambini con DSA nella scuola: dalla Legge 170 alle pratiche didattiche quotidiane IL LAVORO CON I DSA NELLA CLINICA E NELLA SCUOLA: COMPITI ED OBIETTIVI DI CIASCUNO NELL OTTICA DI UN INTERVENTO MULTIDISCIPLINARE

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del A. A. 2004-2005 1 La progettazione È applicata indipendentemente dal modello di processo utilizzato. Parte dal punto in cui sono

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

Lo Studio di Fattibilità

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

Dettagli

IL PERFORMANCE MANAGEMENT

IL PERFORMANCE MANAGEMENT IT PROFESSIONAL SERVICES UNA SOLUZIONE PER IL PERFORMANCE MANAGEMENT for Enterprise Gestire il portfolio applicativo monitorando qualità, produttività e costi dello sviluppo applicativo Overview ARGOMENTI:

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

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO DIREZIONE EMITTENTE CONTROLLO DELLE COPIE Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile

Dettagli

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa La mia scuola ha un sito Web Presentazione del corso Contenuti e obiettivi del corso Imparare a lavorare con le metodologie dell ingegneria del

Dettagli

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland The Scrum Guide La Guida Definitiva a Scrum: Le Regole del Gioco Ottobre 2011 Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland Indice Scopo della Guida Scrum... 3 Overview di Scrum... 3 Scrum Framework...

Dettagli

Piano di gestione della qualità

Piano di gestione della qualità Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo.

Dettagli

Guida al livellamento delle risorse con logica Critical Chain (1^ parte)

Guida al livellamento delle risorse con logica Critical Chain (1^ parte) Paolo Mazzoni 2011. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2011". Non sono ammesse

Dettagli

ORGANIZZAZIONE E GESTIONE DELL INNOVAZIONE

ORGANIZZAZIONE E GESTIONE DELL INNOVAZIONE COME GESTIRE I PROGETTI IN MODO PIÙ SEMPLICE, VELOCE E COLLABORATIVO? COME RENDERE LA PROGETTAZIONE E LO SVILUPPO DEI PRODOTTI PIÙ VELOCE ED EFFICIENTE? COME RIDURRE LA COMPLESSITÀ DEI PRODOTTI GARANTENDO

Dettagli

Gestire il rischio di processo: una possibile leva di rilancio del modello di business

Gestire il rischio di processo: una possibile leva di rilancio del modello di business Gestire il rischio di processo: una possibile leva di rilancio del modello di business Gianluca Meloni, Davide Brembati In collaborazione con 1 1 Le premesse del Progetto di ricerca Nella presente congiuntura

Dettagli

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE La sicurezza delle applicazioni web si sposta a un livello più complesso man mano che il Web 2.0 prende piede.

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 8

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

Dettagli

Object Oriented Programming

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

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

Software a supporto della Gestione amministrativa dello Sportello Unico versione 2.1. Piano d azione

Software a supporto della Gestione amministrativa dello Sportello Unico versione 2.1. Piano d azione Pag. 1 di 6 Software a supporto della Gestione amministrativa dello Sportello Unico versione 2.1 Piano d azione R EV. REDAZIONE VERIFICHE ED APPROVAZIONI CONTROLLO APPROVAZIONE AUTORIZZAZIONE EMISSIONE

Dettagli

COME MISURARE UN SERVICE DESK IT

COME MISURARE UN SERVICE DESK IT OSSERVATORIO IT GOVERNANCE COME MISURARE UN SERVICE DESK IT A cura di Donatella Maciocia, consultant di HSPI Introduzione Il Service Desk, ovvero il gruppo di persone che è l interfaccia con gli utenti

Dettagli

Introduzione. Capitolo 1

Introduzione. Capitolo 1 Capitolo 1 Introduzione Architecture is the set of design decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.

Dettagli

02: Project Management

02: Project Management 02: Project Management Le tre P del project management Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio

Dettagli

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt IT Project Management Lezione 3 Scope Management Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

2 PRINCIPI E VALORI CAP. 2.0 PRINCIPI E VALORI 2.1 SCOPO 2.2 PRINCIPI. 2.2.1 Inclusività

2 PRINCIPI E VALORI CAP. 2.0 PRINCIPI E VALORI 2.1 SCOPO 2.2 PRINCIPI. 2.2.1 Inclusività Pag. 24 / 69 2 2.1 SCOPO Formalizzare e rendere noti a tutte le parti interessate, i valori ed i principi che ispirano il modello EcoFesta Puglia a partire dalla sua ideazione. 2.2 PRINCIPI Il sistema

Dettagli