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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

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

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

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

Dettagli

Introduzione all Ingegneria del Software

Introduzione all Ingegneria del Software Introduzione all Ingegneria del Software Alessandro Martinelli alessandro.martinelli@unipv.it 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software

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

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione 6 Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta Quadri sulla gestione Impiegati con responsabilità direttive Dirigenti di imprese private e organizzazioni pubbliche, interessati

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

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

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

CRAIG LARMAN ROMA 21 NOVEMBRE 2005 ROMA 22-25 NOVEMBRE 2005 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

CRAIG LARMAN ROMA 21 NOVEMBRE 2005 ROMA 22-25 NOVEMBRE 2005 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA CRAIG LARMAN AGILE AND ITERATIVE DEVELOPMENT: A Manager s Guide APPLYING UML AND PATTERNS WORKSHOP: Mastering OOA/D ROMA 21 NOVEMBRE 2005 ROMA 22-25 NOVEMBRE 2005 VISCONTI

Dettagli

Corso di Ingegneria del Software. Modelli di produzione del software

Corso di Ingegneria del Software. Modelli di produzione del software Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali

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

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

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

Progetto di Informatica III

Progetto di Informatica III Progetto di Informatica III Sviluppo Agile (Agile Software Development) Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Metodologia agile Agile Manifesto Che cos è l agilità

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

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

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

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

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

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

Dettagli

modelli casi d uso diagrammi di sequenza di sistema contratti delle operazioni di sistema Capitolo 11

modelli casi d uso diagrammi di sequenza di sistema contratti delle operazioni di sistema Capitolo 11 Luca Cabibbo Analisi e Progettazione del Software Diagrammi di sequenza di sistema Capitolo 10 marzo 2013 In teoria, non c è differenza tra teoria e pratica. Ma, in pratica, c è. Jan L.A. van de Snepscheut

Dettagli

Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi

Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi Quaderno N. 25 Ercole Colonese ercole@colonese.it Roma, 17 dicembre 2007 Argomenti trattati Valutazione del rischio

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

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

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

Dettagli

Il marketing dei servizi. Il gap 2: allineare strategia, modello di servizio e standard di servizio

Il marketing dei servizi. Il gap 2: allineare strategia, modello di servizio e standard di servizio Il marketing dei servizi Il gap 2: allineare strategia, modello di servizio e standard di servizio GAP 2: il gap di progettazione del servizio Il secondo gap del fornitore sta nell incapacità di trasformare

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei

Dettagli

La creazione del valore. Un approccio agile alla trasformazione dell IT

La creazione del valore. Un approccio agile alla trasformazione dell IT Università degli Studi di Padova Dipartimento di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica Relazione finale di tirocinio La creazione del valore. Un approccio agile alla trasformazione

Dettagli

Ingegneria del Software 2

Ingegneria del Software 2 Politecnico di Milano Anno Accademico 2010/2011 Ingegneria del Software 2 Corso della Prof.ssa Elisabetta Di Nitto Stefano Invernizzi Facoltà di Ingegneria dell Informazione Corso di Laurea Magistrale

Dettagli

Sviluppo Agile. Prof. Filippo Lanubile. Processo software

Sviluppo Agile. Prof. Filippo Lanubile. Processo software Sviluppo Agile I processi (di sviluppo) del software bisogni nuovi o modificati Processo software Prodotto software nuovo o modificato Un processo software descrive quali sono le attività che concorrono

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

CRAIG LARMAN ROMA 9 GIUGNO 2008 ROMA 10-13 GIUGNO 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

CRAIG LARMAN ROMA 9 GIUGNO 2008 ROMA 10-13 GIUGNO 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA CRAIG LARMAN Agile and Iterative Development: a Manager s Guide Agile Modeling con UML, Patterns e sviluppo Test-Driven ROMA 9 GIUGNO 2008 ROMA 10-13 GIUGNO 2008 VISCONTI

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

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

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

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

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

Dettagli

Modelli matematici avanzati per l azienda a.a. 2010-2011

Modelli matematici avanzati per l azienda a.a. 2010-2011 Modelli matematici avanzati per l azienda a.a. 2010-2011 Docente: Pasquale L. De Angelis deangelis@uniparthenope.it tel. 081 5474557 http://www.economia.uniparthenope.it/siti_docenti P.L.DeAngelis Modelli

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

Corso semestrale di Analisi e Contabilità dei Costi

Corso semestrale di Analisi e Contabilità dei Costi Corso semestrale di Analisi e Contabilità dei Costi Il target costing Che cosa è il target costing. In prima analisi. E un metodo di calcolo dei costi, utilizzato in fase di progettazione di nuovi prodotti,

Dettagli

Fattori critici di successo

Fattori critici di successo CSF e KPI Fattori critici di successo Critical Success Factor (CSF) Definiscono le azioni o gli elementi più importanti per controllare i processi IT Linee guida orientate alla gestione del processo Devono

Dettagli

Sviluppo e Gestione di Progetti. Primo modulo: Introduzione al PM. Filippo Ghiraldo - Sviluppo e Gestione di Progetti per Informatici

Sviluppo e Gestione di Progetti. Primo modulo: Introduzione al PM. Filippo Ghiraldo - Sviluppo e Gestione di Progetti per Informatici Università di Padova - e Gestione di Progetti Primo modulo: Introduzione al PM docente: Filippo Ghiraldo filippo.ghiraldo@unipd.it Progetti e loro ciclo di vita Esempi Materiale didattico sottoposto a

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

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

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

extreme Programming in un curriculum universitario

extreme Programming in un curriculum universitario extreme Programming in un curriculum universitario Lars Bendix Department of Computer Science Lund Institute of Technology Sweden Università di Bologna, 18 giugno, 2002 Extreme Programming On-site customer

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

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

Cap. 7: L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE

Cap. 7: L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE : L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE Definizioni Per lo sviluppo di un impresa sono necessarie sia le abilità dell imprenditore che quelle dei manager * Le abilità imprenditoriali sono

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

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Gestione dell Informazione Aziendale prof. Stefano Pedrini. Sistemi integrati ERP Addendum 2 Giorgio Cocci, Alberto Gelmi, Stefano Martinelli

Gestione dell Informazione Aziendale prof. Stefano Pedrini. Sistemi integrati ERP Addendum 2 Giorgio Cocci, Alberto Gelmi, Stefano Martinelli UNIVERSITÀ DEGLI STUDI DI BERGAMO Gestione dell Informazione Aziendale prof. Stefano Pedrini Sistemi integrati ERP Addendum 2 Giorgio Cocci, Alberto Gelmi, Stefano Martinelli I sistemi informativi Il processo

Dettagli

LA VALUTAZIONE DEL PERSONALE CON QUALIFICA DIRIGENZIALE SISTEMA DI VALUTAZIONE (Approvato con deliberazione G.P. n.74/2006)

LA VALUTAZIONE DEL PERSONALE CON QUALIFICA DIRIGENZIALE SISTEMA DI VALUTAZIONE (Approvato con deliberazione G.P. n.74/2006) LA VALUTAZIONE DEL PERSONALE CON QUALIFICA DIRIGENZIALE SISTEMA DI VALUTAZIONE (Approvato con deliberazione G.P. n.74/2006) Nel quadro della innovazione organizzativa avviato dalla Provincia, il Nucleo

Dettagli

LARISSA MOSS. Agile Project Management per progetti di Business Intelligence e Data Warehouse

LARISSA MOSS. Agile Project Management per progetti di Business Intelligence e Data Warehouse LA TECHNOLOGY TRANSFER PRESENTA LARISSA MOSS Agile Project Management per progetti di Business Intelligence e Data Warehouse ROMA 15-16 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami Echi da Amsterdam Sintesi del Leadership Meeting e dell EMEA Congress 2009 Titolo: Sintesi presentazioni Metodologia Agile Relatore: Bruna Bergami PMI NIC - Tutti i diritti riservati Milano, 19 Giugno

Dettagli

ISO Revisions Whitepaper

ISO Revisions Whitepaper ISO Revisions ISO Revisions ISO Revisions Whitepaper Processi e procedure Verso il cambiamento Processo vs procedura Cosa vuol dire? Il concetto di gestione per processi è stato introdotto nella versione

Dettagli

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab.

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab. Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Gli elementi che caratterizzano il Sistema Qualità e promuovono ed influenzano le politiche di gestione delle risorse

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