Progettazione del Software appunti dalle lezioni

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Progettazione del Software appunti dalle lezioni"

Transcript

1 Progettazione del Software appunti dalle lezioni Marco Gasparini Carlo Pane Francesco Solera Università degli Studi di Modena e Reggio Emilia

2 Progettazione del Software, appunti dalle lezioni This report was prepared by Marco Gasparini, Carlo Pane, Francesco Solera Professor Flavio Bonfatti Release date: 2011 Course: Progettazione del Software Department: Comments: Ingegneria Informatica Questo breve documento vuole essere un supporto didattico alle lezioni del corso di Progettazione del Software. È stato scritto a partire dagli appunti presi a lezione ed integrato, qualora ritenuto necessario, con materiale dai libri di testo indicati dal docente e riportati nella bibliografia. Department of Information Engineering Information Technologies and Computer Science University of Modena e Reggio Emilia

3 Introduzione Il corso è indirizzato agli studenti della Laurea Magistrale in Ingegneria Informatica ai quali intende fornire le conoscenze e gli strumenti metodologici fondamentali per l impostazione, l organizzazione e la gestione di progetti software complessi e di grandi dimensioni. Gli argomenti trattati sono: : Economia di un progetto software. Fattibilità di un progetto software, metodo PERT-CPM. Classificazione delle tecniche di stima dei costi e dei tempi di un progetto. Metodo CoCoMo di Boehm (modello base, modello intermedio, cenni al modello dettagliato). Funzione costo di Norden e metodo analitico di Putnam. Le principali variabili di un progetto software. Progetto di piccole, medie e grandi dimensioni secondo Putnam. Curva di sviluppo e curva di progetto. Equazione del software. Software sizing per progetti nuovi e per rifacimenti. Studio del progetto tramite planning zone e punto di lavoro. Metodi avanzati di progettazione del software. Il Processo Unificato (UP). Metodi agili di sviluppo del software e loro principali caratteristiche. Il metodo Agile UP. Il metodo SCRUM. Il metodo Feature Driven Development (FDD). Il metodo Dynamic Systems Development (DSDM). Il metodo Extreme Programming (XP). Tecniche agili di sviluppo del software. Cross-functional team, time boxing, pair programming, test-driven development, code re-factoring. Confronto critico dei diversi approcci. Software Process Improvement (SPI) e Capability Maturity Method integration (CMMi). Linguaggi formali e tecniche di compilazione. Alfabeto, stringa, linguaggio e relativi operatori. Espressioni e linguaggi regolari. Grammatiche generative, definizione formale e classificazione di Chomsky. Grammatiche non contestuali. Alberi sintattici, ambiguit della grammatica. Grammatiche strettamente lineari sinistre, equivalenza con espressioni regolari. Automi a stati finiti, equivalenza con grammatiche strettamente lineari sinistre. Automi non deterministici. Derivazione degli automi deterministici equivalenti, automi minimi. Notazione polacca postfissa e forma a quadruple, generazione del codice oggetto.

4

5 Contents II Metodi avanzati di progettazione del software 1 1 Il Processo Unificato Caratteristiche dello Unified Process Ciclo di vita del progetto Rational Unified Process Modelli agili di progettazione e sviluppo del software Agile UP Scrum FDD Dynamic System Development Method XP Sistemi di qualità ISO Capability Maturity Model integration III Linguaggi formali e tecniche di compilazione 43

6

7 Part II Metodi avanzati di progettazione del software 1

8

9 Chapter 1 Il Processo Unificato Fino ad ora abbiamo sempre avuto a che fare con un metodo di progettazione del software chiamato a cascata. Il modello a cascata o ciclo di vita a cascata (waterfall model o waterfall lifecycle in inglese) è un modello di ciclo di vita del software (ovvero di processo software) secondo cui la realizzazione di un prodotto software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto, sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso output che viene utilizzato come input per la fase successiva. Purtroppo questo modello viene definito rigido, poiché una volta terminata una fase, questa viene bloccata e diventa insensibile a nuovi requisiti che il cliente potrebbe chiedere o modifiche che il team di sviluppo riconosce come necessarie. Quando si sviluppano software medio-grandi con un modello a cascata occorre mettersi nell ottica che: Il 25%-50% dei requisiti probabilmente cambieranno durante la durata del progetto Almeno il 45% dei requisiti implementati non saranno utilizzati dal cliente Il cliente finanziatore non vedrà niente fino alla fine del processo di sviluppo del software Spesso questi vincoli non risultano essere apprezzati nè dal cliente, che inizia a vedere i risultati dopo lunghi mesi dal momento del finanziamento, nè per il team di sviluppo che è costretto a fare i conti con la rigidità e la linearità di questo approccio. Da queste necessità è nato un nuovo paradigma di progettazione, chiamato Unified Process. Lo UP non è un semplice processo ma piuttosto un framework, un ambiente di lavoro, che dovrebbe essere personalizzato per particolari aziende e progetti. Anche lo Unified Process divide il tempo di sviluppo del software in fasi: Inception, Elaboration, Construction e Transition; per ognuna di queste fasi sono definiti obiettivi ben chiari, ma nessun particolare vincolo è imposto sulle differenti discipline necessarie allo sviluppo (come ad esempio i requisiti). Questa caratteristica permette di riprendere in mano il lavoro già svolto anche in fasi successive e di 3

10 1.1. Caratteristiche dello Unified Process procedere in maniera parallela verso il momento di rilascio del prodotto. Lo UP è particolarmente gradito anche al cliente che può toccare con mano l evoluzione del suo software in una sempre maggiore implementazione dei requisiti. 1.1 Caratteristiche dello Unified Process Iterativo ed incrementale Lo UP è un processo di sviluppo iterativo ed incrementale. Le fasi di Elaboration, Construction and Transition sono divise in una serie di iterazioni di durata definita. Ogni iterazione risulta in un incremento, ovvero in un rilascio del prodotto che contiene funzionalità aggiunte o migliorate rispetto alla release precedente. Nonostante la maggior parte delle iterazioni includeranno contributi da una buona parte delle discipline (requisiti, analisi, progettazione, implementazione e testing), l importanza di questi contributi cambierà nel corso del progetto. Basato sugli Use Case Nello UP, i casi d uso sono usati per catturare i requisiti funzionali e per definire il contenuto di ogni iterazione. Ogni iterazione si occupa di gestire un certo sottoinsieme di casi d uso o di scenari dai requisiti fino all implementazione, test e rilascio. Incentrato sull architettura Per lo UP è importante che l architettura del software sia alla base della preoccupazione e degli sforzi del team di sviluppo. In quanto nessun modello da solo è sufficiente per catturare tutti gli aspetti del sistema, lo UP supporta vari modelli architetturali. Uno degli impegni più importanti del processo di sviluppo è l architettura della baseline eseguibile che viene creata durante la fase di Elaboration. Questa implementazione parziale, dovrebbe rispondere ai requisiti critici e caratteristici individuati in fase di analisi dei requisiti e serve per validare l architettura globale del progetto. Inoltre diventerà, se ritenuta valida, la base per il resto dello sviluppo del software. Pilotato dai fattori di rischio Lo UP richiede che il team di sviluppo sia preoccupato di risolvere i rischi più critici nelle prime fasi del progetto. 1.2 Ciclo di vita del progetto Come già accennato anche lo UP prevede che il ciclo di vita del progetto sia suddiviso in quattro fasi. 4

11 1.2. Ciclo di vita del progetto Il grafo RAPIT Il grafo RAPIT (Requisiti, Analisi, Progettazione, Implementazione, Test) permette di caratterizzare dinamicamente per ogni progetto quando e con quale importanza le varie discipline della progettazione del software entreranno in gioco nelle varie fasi di sviluppo del prodotto. Figure 1.1: Il grafo RAPIT, mette in relazione le discipline della progettazione del software con le fasi di sviluppo del prodotto. Inception L inception è la fase più breve nella progettazione, e così deve essere: una fase di inception prolungata indica un eccessivo lavoro di specificazione a priori, che è contrario allo spirito dello UP. Obiettivo: definire a grandi linee ciò che il software dovrà fare. Artefatti: requisiti principali, valutazione dei rischi, glossario del progetto, una prima documentazione dell architettura, una prima pianificazione dello sviluppo e i prototipi. Elaboration Durante la fase di Elaboration, il team di sviluppo dovrebbe catturare la maggior parte (si può stimare un 80%) dei requisiti del software finale. Comunque lo scopo principale di questa fase è quella di produrre una prima baseline eseguibile che verifichi l appropriatezza del modello architetturale adottato. Una baseline è un implementazione parziale del sistema che include il cuore e le specifiche caratterizzanti del progetto. È costruito e migliorato ciclicamente in una serie di iterazioni e per la fine della fase di elaborazione il modello architetturale deve essere fissato e rimanere stabile fino alla fine dello sviluppo, inoltre la baseline eseguibile deve dimostrare che la scelta dell architettura si rivela appropriata per supportare le funzionalità chiave del prodotto in termini di performance, scalabilità e costi. Obiettivi: creare una baseline eseguibile, perfezionare la valutazione dei rischi, creazione dei casi d uso di circa l %80 dei requisiti fornendo alla fase di costruzione 5

12 1.3. Rational Unified Process una solido piano (di costi e di scadenze) su cui lavorare. Artefatti: baseline, disegno architetturale, documento di valutazione dei rischi, diagrammi dei casi d uso, pianificazione dettagliata. Construction La Construction è la fase più lunga della progettazione. In questa fase quello che rimane del sistema è costruito a partire dalla baseline prodotta dalla fase di Elaboration. Le caratteristiche del software sono sviluppate durante una serie di iterazioni di piccola durata alla fine delle quali deve essere prodotto una nuova baseline eseguibile. Durante questa fase vengono spesso impiegate tecniche di progettazione UML(Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams). Obiettivo: capacitò operativa basilare, ovvero la release prodotta da questa fase deve permettere già l utilizzo delle funzioni caratteristiche del software. Artefatti: prodotto software, modellazione UML, una prima versione del manuale utente ed un piano di testing. Transition La fase finale del progetto è la Transition. In questa fase il sistema è consegnato all utente finale. Con il feedback ricevuto da una release iniziale uscente dalla prima iterazione è possibile apportare modifiche e ridefinire scelte implementative. Obiettivi: rilascio del prodotto, correzione dei difetti, formazione degli utenti utilizzatori. Artefatti: prodotto software testato, risultato del test d accettazione, manuali d uso aggiornati alla release definitiva e accordo di mantenimento. 1.3 Rational Unified Process Il Rational Unified Process (RUP) (che è una estensione dello Unified Process) è un modello di processo software iterativo ed incrementale sviluppato da Rational Software (oggi parte di IBM). Fornisce un approccio disciplinato per l assegnazione dei compiti e delle responsabilità all interno dello sviluppo di un progetto. Il suo obiettivo è assicurare la produzione di un software di alta qualità che incontra i bisogni dei clienti, pur rimanendo all interno di un budget e di una tempistica predefiniti. Caratteristico di questa metodologia è occuparsi di descrivere chi sta facendo cosa, come e quando. Il Rational Unified Process è rappresentato usando quattro elementi primari di modellazione: Workers, the "who": definisce il comportamento e le responsabilità di un individuo, o un gruppo di individui che lavorano insieme come team Activities, the "how": sono unità di lavoro che un individuo in quel ruolo può svolgere, la granularità di un attività è tipicamente dell ordine di poche ore o pochi giorni 6

13 1.3. Rational Unified Process Artifacts, the "what": è un pezzo di informazione che è prodotto, modificato o usato da un processo, gli artefatti sono prodotti tangibili del processo Workflows, the "when": è una sequenza di attività che produce un risultato di valore osservabile Ci sono nove core process workflows o fasi specificate dal modello RUP, le quali rappresentano una partizione di tutti i lavoratori e attività in gruppi logici. Le fasi del ciclo di sviluppo del software sono divise in sei engineering workflows: 1. Business modeling workflow 2. Requirements workflow 3. Analysis & Design workflow 4. Implementation workflow 5. Test workflow 6. Deployment workflow E tre workflows di supporto : 1. Environment workflow 2. Configuration and Change Management workflow 3. Project Management workflow Anche se i nomi delle sei discipline ingegneristiche possono richiamare un idea di processo a cascata, dobbiamo tenere in mente che sono fasi di un processo iterativo e differiscono da queste in quanto sono riviste e riviste per tutta la durata del ciclo di sviluppo del software. Business modeling Uno dei problemi principali nella fase iniziale di progettazione di un software è che il team di software engineering ed il team di business engineering non comunicano in modo appropriato. Questo comporta che il risultato prodotto dal business engineering non è usato in modo appropriato dal team di software engineering e vice versa. Il RUP fornisce un linguaggio ed una metodologia comune per tenere sincronizzati i modelli business e software. Requirements. L obiettivo di questo workflow è di descrivere cosa il sistema dovrebbe fare e permettere agli sviluppatori ed ai clienti di concordare su tale descrizione. Per ottenere questo esplicitiamo, organizziamo e documentiamo le funzionalità, i vincoli e le decisioni prese in fase di analisi. Analysis & Design Il goal principale qui è di far vedere come il sistema sarà realizzato nella successiva fase d implementazione. In breve realizza un astrazione del codice che realizzerà i requisiti individuati. 7

14 1.3. Rational Unified Process Test Gli scopi della fase di testing sono: verificare l interazione fra gli oggetti, verificare l integrazione di tutti i componenti del software, verificare che i requisiti siano tutti correttamente soddisfatti, individuare eventuali problemi prima del rilascio del software. Deployment Lo scopo di questa fase è quello di produrre con successo il rilascio del software e distribuirlo all utente finale. Questa fase comprende anche l assistenza e l aiuto all utente. Environment L obiettivo del workflow di environment è quello di fornire al team di sviluppo un ambiente, che comprende sia metodologie che strumenti, necessari per la progettazione del prodotto, in particolare è importante chiarire le attività volte all inquadramento del processo all interno di un progetto. Configuration and Change Management In questo workflow è descritto come controllare i numerosi artefatti prodotti dalle tante persone che lavorano su un progetto comune. Avere controllo su questo piano significa evitare confusione e assicurare che gli artefatti risultanti non siano in conflitto con altri a causa di accessi multiplo, aggiornamenti simultanei o limitate notifiche. Project Management Software Project Management è l arte di bilanciare gli obiettivi paralleli di un software, gestire i rischi e superare i vincoli, al fine di rilasciare un prodotto che incontra i bisogni del cliente e degli utilizzatori finali. Sviluppo efficace e buone pratiche Il RUP descrive alcune pratiche che sono state osservate in progetti di successo e che si ritiene possano essere d aiuto nello sviluppare in modo efficace software commerciale. Develop software iteratively: data la complessità dei software di oggi è impossibile delineare prima l intero problema, disegnare una soluzione e poi costruire il software e testarlo; è necessario un approccio iterativo che permetta di inserire nella progettazione la comprensione sempre maggiore che il team di sviluppo ha sul problema e sulle funzionalità. Manage requirements: gestire in modo efficiente i requisiti funzionali è fondamentale per la buona riusciuta del software; è importante fin da subito esplicitare, organizzare e documentare le funzionalità richieste ed i vincoli imposti al fine di poter trarre decisioni e valutare compromessi, l importanza di questa pratica è data dal fatto che l implementazione parte proprio da queste considerazioni. Use component-based architectures: il processo si focalizza sull inizio della fase implementativa, si tratta di buttare delle fondamenta che siano robuste e flessibili al tempo stesso, prima di arrivare ad avere una quantità di codice che 8

15 1.3. Rational Unified Process risulta mal strutturata ed ingestibile; a tale scopo sono importanti i concetti di riusabilità e modularità. Visually model software: si tratta di accompagnare alla documentazione scritta anche una modellazione visuale del comportamento dell architettura e dei componenti; questo permette di nascondere inutili dettagli e facilitare la comunicazione di aspetti critici del software. Verify software quality: scarse prestazione e poca affidabilità sono fattori che incidono pesantemente sull accettabilità dei software moderni, quindi la qualità dovrebbe essere valutata tenendo in considerazione fattori come l affidabilità, il rispetto dei requisiti e le performance dell applicazione e del sistema. Control changes to software: l abilità di gestire modifiche - essere sicuri che ogni modifica sia accettabile e rintracciabile - è essenziale in un ambiente in cui le modifiche sono inevitabili. 9

16 1.3. Rational Unified Process 10

17 Chapter 2 Modelli agili di progettazione e sviluppo del software Nell ingegneria del software, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste. La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software. Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto. I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia a faccia, a quella scritta (documentazione). Il team agile è composto da tutte le persone necessarie per terminare il progetto software. Come minimo il team deve includere i programmatori ed i loro clienti (con clienti si intendono le persone che definiscono come il prodotto dovrà essere fatto: possono essere dei product manager, dei business analysts, o veramente dei clienti). L agile manifesto La formalizzazione dei principi su cui si basano le metodologie leggere è stata oggetto del lavoro di un gruppo di progettisti software e guru dell informatica che si sono spontaneamente riuniti nell Agile Alliance. Il documento finale di questo lavoro è stato poi sottoscritto da un nutrito gruppo di questi professionisti, molti dei quali hanno anche sviluppato alcune delle metodologie leggere più famose. L obiettivo è la piena soddisfazione del cliente e non solo l adempimento di un contratto. L uso di queste metodologie, inoltre, serve ad abbattere i costi di sviluppo 11

18 Modelli agili di progettazione e sviluppo del software del software. Principi I principi su cui si basa una metodologia leggera che segua i punti indicati dall Agile Manifesto, sono solo quattro: le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto) è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile) bisogna collaborare con i clienti al di là del contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali) bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto (quindi il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento) Considerazioni e buone pratiche La metodologia leggera non nasce per caso, ma come presa di consapevolezza che alcune cose nel mondo della progettazione non andavano. Essa, proprio perché nasce da alcune considerazioni fondanti fornisce e suggerisce alcune pratiche che è bene avere in mente. Risulta particolarmente importante, ad esempio, rilasciare frequentemente software con nuove funzionalità mantenendo in questo modo alta la soddisfazione del cliente. Infatti un software che funziona è molto più apprezzato di un mucchio di documentazione e di fogli di progettazione in corso d opera. Proprio per come è strutturata la metodologia, anche il development team deve essere disposto ad accettare nuovi requisiti, nuove funzionalità da inserire all interno del software anche in fase di implementazione. Questo forse è uno dei frutti principali della stretta collaborazione fra sviluppatori e clienti, il rapporto faccia a faccia impedisce che ci siano periodi di inutile lavoro sprecato poiché cambiato all ultimo. Se il contatto con il cliente è continuo, allora la progettazione risulterà più fluida. Infine il rischio di utilizzare queste metodologie agili, è quello di credere che la progettazione formale sia in secondo piano, il che non è assolutamente vero: è infatti importantissimo tenere in mente che obiettivo principale è sempre quello dell eccellenza tecnica e della qualità. L approccio agile contrappone un approccio adattativo (perché consente di rivedere di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e di pareri con il committente) rispetto ad uno predittivo (basato su una precisa pianificazione iniziale). È comunque necessario precisare che le metodologie agili non eliminano il concetto di progettazione, semplicemente è una fase trasversale a tutto il ciclo di sviluppo del software. I metodi agili hanno anche altri limiti oltre all inevitabile abbassamento della qualità, riguardante la motivazione. Ossia, per portare avanti un progetto secondo questa metodologia sono necessarie persone disponibili e con particolare esperienza; 12

19 Modelli agili di progettazione e sviluppo del software inoltre le tecniche agili non si comportano bene con progetti enormi, con team distribuiti geograficamente, in aziende che sono particolarmente strutturate e gerarchiche, proprio perché queste situazioni intaccano i principi fondamentali dell Agile Manifesto. Principi comuni dei modelli agili Sin dall inizio deve essere chiaro che questi approcci agili non sono la soluzione a tutti i problemi, non hanno nessuna intenzione di abolire i metodi tradizionali, ma possono introdurre un nuovo modo di affrontare particolari problemi. L approccio agile funziona molto bene in progetti a bassa criticità, se guidati da sviluppatori senior, per software nuovi con requisiti ancora in fase di analisi. Di questi metodi ce ne sono vari, i più famosi sono probabilmente Agile UP, Scrum, FDD, DSDM ed XP. Anche se agili, questi metodi si fondano su un insieme di tecniche, pratiche che permettono di disciplinare la progettazione (Cross-functional team, Time-boxing, Pair programming, Test-driven development, Code refactoring). Le singole pratiche applicabili all interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell azienda e dall approccio del project manager, tuttavia alcune sono comuni. Cross-functional team È l idea di creare team di sviluppo capace di portare avanti simultaneamente tutte le discipline della progettazione del software, quindi dall analisi dei requisiti, implementazione, test, etc. Ha la caratteristica di essere self-directed, riceverà direttive ampie e generali da parte del managment, ma è il team stesso che decide come organizzarsi e come procedere con la progettazione. Questa tecnica porta con sè vari benefici, a partire dal modo di raggiungere gli obiettivi, che passa da uni-directional ad una dinamica interna più ampia; non è prestabilito chi fa che cosa, giorno per giorno. Le informazioni usate dal team per svolgere le proprie azioni è più ampia, più ricca rispetto a quelle di un gruppo monofunzionali (greater scope of information). Non solo, oltre la vastità di informazioni, anche la profondità di queste è notevolmente migliore (greater depth of information): supponiamo di essere in un gruppo di sola implementazione, allora tutto il team potrebbe lavorare esclusivamente su quello che è già stato deciso e congelato dagli analisti precedentemente; al contrario, in un cross-functional team possono essere considerati e rivalutati molti più aspetti, anche in fase di implementazione. Anche le persone coinvolte nel team ne traggono beneficio, non è più possibile utilizzare un gergo specifico o approssimativo nello svolgimento del proprio lavoro; ora che si lavora in un gruppo interfunzionale è necessario essere comprensibili anche ai membri specifici di altre discipline. Time-boxing Questa pratica impone di dividere la progettazione in una serie definita di intervalli di tempo prestabiliti, all interno dei quali il lavoro deve essere portato a termine. Se prima la logica era più incentrata sugli obiettivi (ed il tempo si allungava fino all esaurimento dell obiettivo), ora con il time-boxing è il tempo disponibile ad essere definito (ed eventualmente gli obiettivi vengono ridotti). È importante quindi, che gli obiettivi vengano fin da subito commisurati con più real- 13

20 Modelli agili di progettazione e sviluppo del software ismo al tempo necessario per portarli a termine. All esaurire del tempo predefinito, se l obiettivo è ancora in fase di compimento, posso decidere se cancellare o rischedulare il lavoro in time-boxes successive. Se il vero vincolo del progetto è il tempo di sviluppo, questa tecnica risulta particolarmente benefica. Il time-boxing può essere utilizzata in piccola scala anche da una singola persona che voglia ottimizzare il proprio tempo. Pair programming Questa tecnica agile impiegata in vari metodi consiste nel realizzare lo sviluppo del codice in due persone che se ne stanno insieme davanti al display, uno con il ruolo di driver ed uno con il ruolo di navigator e con lo scambio di questi ruoli particolarmente frequente (30 minuti). Il driver scrive il codice, mentre il navigator anche non volendo svolge un ruolo particolarmente importante: ragiona sull analisi, cioè mentalmente verifica in modo continuativo se il codice scritto rispecchia la sua idea di implementazione dei requisiti, poi inizia a progettare ciò che segue al codice scritto dal driver; infine evidentemente assume un ruolo da debugger in real time, individuando gli errori compiuti dal compagno. È un modo di lavorare molto interessante, che presenta vari benefici ma anche vari limiti di applicazione. Fra i benefici attesi c è la qualità del risultato che risulta essere perfettamente leggibile da due persone, e la cui chiarezza può essere apprezzata anche al di fuori del tipico programmatore, probabilmente il codice risulta essere particolarmente semplice anche se ugualmente efficace. Inoltre, in modo paradossale, il costo del progetto si riduce notevolmente (studi riconoscono l incremento del tempo di programmazione del 15%, ma il 50% in meno degli errori risultante in un 20%-40% riduzione del tempo nella fase di debugging e testing). Questa tecnica può essere utilizzata anche per la formazione di nuovi programmatori, che risultano essere autonomi molto più velocemente che con metodi di apprendimento tradizionali. Risulta didattica anche la scelta di accostare due principianti, che possono aiutarsi nell analisi e nel superamento delle difficoltà. Infine, se per qualche ragione, un dipendente abbandona l azienda, rimane la sicurezza di conoscere il codice. D altra parte, non tutti hanno l attitudine a collaborare e per alcuni l esperienza del pair-programming potrebbe non essere piacevole. Anche un principiante rischia di sentirsi inappropriato ed intimidido se di supporto ad un senior programmer, il quale fra l altro rischia di annoiarsi. Possono inoltre nascere potenziali conflitti dovuti alle differenti metodologie di programmazione utilizzati o dovuti al senso di competizione che può scaturire fra i due. Test-driven development Nello sviluppare il codice, per prima cosa, viene scritto un test sul codice ancora inesistente. Successivamente scrivo il codice che deve superare il test progettato. Se il codice supera il test, allora penso un altro test, altrimenti devo tornare sul codice e cambiarlo. Questo procedimento richiede un ambiente adeguato per scrivere test e sottoporre ai test frammenti di codice. Una seconda osservazione è sulla scrittura dei test: essi sono scritti in modo lineare rispetto allo sviluppo del codice, quindi può risultare particolarmente utile lavorare in coppia, in modo che se uno ha pensato il test, l altro scrive il codice senza sapere come è stato strutturato e quindi viene evitato il rischio di scrivere codici con il solo scopo di passare il test. Nonostante questo l approccio è completamente diverso dal 14

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

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

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

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

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

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 Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2015 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

Dettagli

Modelli di Processo. www.vincenzocalabro.it

Modelli di Processo. www.vincenzocalabro.it Modelli di Processo Il Modello del Processo Il modello del processo stabilisce i principi di base su cui si fonda lo sviluppo del software (e a cui è dovuto il successo o l insuccesso) Non esiste un unico

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

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

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

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

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 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

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

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

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

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

* 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

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

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

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

Riccardo Sponza Technical Evangelism Manager Microsoft Italia

Riccardo Sponza Technical Evangelism Manager Microsoft Italia Riccardo Sponza Technical Evangelism Manager Microsoft Italia SOA/EDA Composite Apps Software + Services Esercizio EAI Integrazione Punto-a-Punto Web services Consolidamento dell Infrastruttira Razionalizzazione

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

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

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

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

Dettagli

Classificazione Nuovo Esame PMP

Classificazione Nuovo Esame PMP Notizie sul nuovo esame PMP a partire dal Agosto 0 Classificazione Nuovo Esame PMP Questo è il link al documento del PMI: Crosswalk Between Current and New PMP Classifications del PMI Di seguito trovi

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

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

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

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

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

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

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro Processi di Sviluppo Software Introduzione Giuseppe Calavaro Processi di sviluppo software - Agenda Differenza tra Programmazione e Progettazione SW I Processi di Sviluppo Software Waterfall Spirale RUP

Dettagli

Università degli Studi dell Insubria

Università degli Studi dell Insubria Università degli Studi dell Insubria FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Informatica Studio e applicazione di metodi agili nello sviluppo di prodotti Software Open Source

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

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

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

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore METODI AGILI PER IL CONTROLLO DI GESTIONE 1 Fonte: Smaldore, L.G. (2014), Metodi «Agili» per il Controllo di Gestione, in Busco C., Giovannoni E. e Riccaboni A. (a cura di), Il controllo di gestione. Metodi,

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

Dettagli

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

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

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

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

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

Il Processo Software

Il Processo Software Il Processo Software 29-03-2012 Prodotto Software Prodotto di qualità Tempi e costi determinati Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento Processo

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

IL BS7799 ALCUNI CONCETTI FONDAMENTALI. Relatore: Ing. Marcello Mistre, CISA marcello.mistre@sistinf.it BS 7799. Sistemi Informativi S.p.A.

IL BS7799 ALCUNI CONCETTI FONDAMENTALI. Relatore: Ing. Marcello Mistre, CISA marcello.mistre@sistinf.it BS 7799. Sistemi Informativi S.p.A. IL BS7799 Relatore: Ing. Marcello Mistre, CISA marcello.mistre@sistinf.it Sistemi Informativi S.p.A. ALCUNI CONCETTI FONDAMENTALI Sistemi Informativi S.p.A. 2 ATTIVITA DELLA SECURITY STUDIO, SVILUPPO ED

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

Manutenzione del software

Manutenzione del software del software Generalità Leggi dell evoluzione del software Classi di manutenzione Legacy systems Modelli di processo per la manutenzione 1 Generalità La manutenzione del software è il processo di modifica

Dettagli

Pubblicazioni COBIT 5

Pubblicazioni COBIT 5 Pubblicazioni COBIT 5 Marco Salvato CISA, CISM, CGEIT, CRISC, COBIT 5 Foundation, COBIT 5 Trainer 1 SPONSOR DELL EVENTO SPONSOR DI ISACA VENICE CHAPTER CON IL PATROCINIO DI 2 La famiglia COBIT 5 3 Aprile

Dettagli

1. L Ingegneria del Software

1. L Ingegneria del Software 1. L Ingegneria del Software Obiettivi della lezione: Definire cosa si intende per Ingegneria del Software Discutere i concetti di prodotto software e di processo software Spiegare il concetto di visibilità

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

The Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture The Zachman Framework for Enterprise Architecture Introduzione Una delle sfide più importanti che un impresa moderna deve affrontare è quella del cambiamento. Considerando la necessità di cambiamento dal

Dettagli

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita Processi software Anno accademico 2009/10 Ingegneria del mod. A Tullio Vardanega, tullio.vardanega@math.unipd.it SCD IS Definizioni Ciclo di vita Copre l evoluzione di un prodotto dal concepimento al ritiro

Dettagli

Introduzione all ambiente di sviluppo

Introduzione all ambiente di sviluppo Laboratorio II Raffaella Brighi, a.a. 2005/06 Corso di Laboratorio II. A.A. 2006-07 CdL Operatore Informatico Giuridico. Introduzione all ambiente di sviluppo Raffaella Brighi, a.a. 2005/06 Corso di Laboratorio

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

Il Processo Software

Il Processo Software Il Processo Software 03/04/13 Prodotto Software Prodotto di qualità Tempi e costi determinati Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento Processo Software

Dettagli

Ingegneria del Software T. 2. Analisi orientata agli oggetti

Ingegneria del Software T. 2. Analisi orientata agli oggetti Ingegneria del Software T 2. Analisi orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare

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

Quali passi per introdurre l Agile in azienda?

Quali passi per introdurre l Agile in azienda? Quali passi per introdurre l Agile in azienda? Garantire reattività e prontezza in uno scenario sempre più dinamico Quali passi per introdurre l Agile in azienda? White Paper Nell attuale contesto di mercato,

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

Processi per lo sviluppo rapido del software

Processi per lo sviluppo rapido del software Lezione 3 Processi per lo sviluppo rapido del software Sviluppo Rapido del Software Slide 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.17 R. Pressman- Principi di

Dettagli

La progettazione del software nelle piccole o micro imprese

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

Dettagli

TEMPLATE FOR CC MEMBERS TO SUBMIT QUESTIONS AT THE 22 nd MEETING OF THE EA CERTIFICATION COMMITTEE

TEMPLATE FOR CC MEMBERS TO SUBMIT QUESTIONS AT THE 22 nd MEETING OF THE EA CERTIFICATION COMMITTEE Agenda Item 9 EACC(11)M22Prep-QUESTIONS TEMPLATE FOR CC MEMBERS TO SUBMIT QUESTIONS AT THE 22 nd MEETING OF THE EA CERTIFICATION COMMITTEE WARNING: Documento NON UFFICIALE. Quando disponibile il verbale

Dettagli

Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it. Ing.Ezio MIOZZO

Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it. Ing.Ezio MIOZZO Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it 1 Indice Il contesto Metodologie Agili L extreme Project Management Lean Thinking o pensiero Snello Convergenza dei vari approcci 2 Contesto Da

Dettagli

ESI International. Project Management & Business Analysis Solutions. www.esi-italy.it

ESI International. Project Management & Business Analysis Solutions. www.esi-italy.it ESI International Project Management & Business Analysis Solutions www.esi-italy.it Chi siamo Leader globali nei servizi di PERFORMANCE IMPROVEMENT in: Project Management Business Analysis Agile Project

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

3. SOFTWARE MANAGEMENT

3. SOFTWARE MANAGEMENT 3. SOFTWARE MANAGEMENT Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling)

Dettagli

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013 Ingegneria del Software Testing Corso di Ingegneria del Software Anno Accademico 2012/2013 1 Definizione IEEE Software testing is the process of analyzing a software item to detect the differences between

Dettagli

Software. Engineering

Software. Engineering Software Il modello CMMI Engineering nelle organizzazioni software Agenda Focalizzazione sul processo CMMI come modello per il miglioramento dei processi Struttura del modello CMMI Aree di processo Riferimenti

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2.

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2. Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto Project Management Dott. Andrea F. Abate e-mail: abate@unisa.it Web: http://www.dmi.unisa.it/people/abate Gestione di Progetti Software: Pianificazione delle attività e rappresentazioni grafiche Obiettivi

Dettagli

CA-Clarity Vision. Governare la trasformazione delle idee in iniziative di business con un approccio agile Fabio Cresta Principal Consultant

CA-Clarity Vision. Governare la trasformazione delle idee in iniziative di business con un approccio agile Fabio Cresta Principal Consultant CA-Clarity Vision Governare la trasformazione delle idee in iniziative di business con un approccio agile Fabio Cresta Principal Consultant Legame tra fallimento dei progetti e requisiti Il 70-80% dei

Dettagli

Seminario Metodi Agili per la gestione dei progetti per Decision Makers

Seminario Metodi Agili per la gestione dei progetti per Decision Makers Seminario Metodi Agili per la gestione dei progetti per Decision Gestire la complessità, adattarsi al cambiamento. Velocemente. Questa è la sfida quotidiana di ogni manager, sia in campo IT che in tutti

Dettagli

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti Progettazione del Software L3.1 Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw (Basato su materiale didattico

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

Approcci agili per affrontare la sfida della complessità

Approcci agili per affrontare la sfida della complessità Approcci agili per affrontare la sfida della complessità Firenze, 6 marzo 2013 Consiglio Regionale della Toscana Evento organizzato dal Branch Toscana-Umbria del PMI NIC Walter Ginevri, PMP, PgMP, PMI-ACP

Dettagli

Ingegneria dei Requisiti

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

Dettagli

Introduzione all Agile Software Development

Introduzione all Agile Software Development IBM Rational Software Development Conference 5RPDRWWREUH 0LODQR RWWREUH Introduzione all Agile Software Development 0DULDQJHOD2UPH Solution Architect IBM Rational Services PRUPH#LWLEPFRP 2008 IBM Corporation

Dettagli

Introduzione a UML. Iolanda Salinari

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

Dettagli

Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One - Oracle

Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One - Oracle FACOLTÀ DI INGEGNERIA RELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA SPECIALISTICA IN INGEGNERIA GESTIONALE Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One

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

Fondamenti di Informatica 7. Linguaggi di programmazione

Fondamenti di Informatica 7. Linguaggi di programmazione I linguaggi di alto livello Fondamenti di Informatica 7. Linguaggi di programmazione Introduzione alla programmazione Caratteristiche dei linguaggi di programmazione I linguaggi di programmazione di alto

Dettagli

Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software

Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software Edizioni Della Vigna Indice PREFAZIONE... XIII RICHIAMI DI PROJECT MANAGEMENT... 19 1.1 - Introduzione al project management...

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

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U.

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U. Università degli studi dell Aquila Sistemi informativi aziendali 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti (2 ore)

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali

Università degli studi dell Aquila. Sistemi informativi aziendali Università degli studi dell Aquila Sistemi informativi aziendali 6 C.F.U. 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

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

Dettagli

ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop. Ernesto Viale 1 Dicembre 2011

ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop. Ernesto Viale 1 Dicembre 2011 ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop Ernesto Viale 1 Dicembre 2011 Skytechnology srl Skytechnology è una società di ingegneria,

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

Glossario Project Cycle Management

Glossario Project Cycle Management Glossario Project Cycle Management Albero degli obiettivi Diagramma, utilizzato nell ambito dell Approccio del Quadro Logico, che permette di rappresentare, in un quadro unitario, ciò che si potrebbe osservare

Dettagli

L ambito di progetto Rappresenta la definizione del progetto, ovvero cosa deve essere portato a termine Comprende gli elementi:

L ambito di progetto Rappresenta la definizione del progetto, ovvero cosa deve essere portato a termine Comprende gli elementi: Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 6: Ambito di progetto organizzazione della comunicazione Prof.ssa R. Folgieri email: folgieri@dico.unimi.it folgieri@mtcube.com

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE

LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN BENNEKUM AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE ROMA 16-17 NOVEMBRE 2015 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza. Flavio Tonetto - 4 maggio 2015

La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza. Flavio Tonetto - 4 maggio 2015 La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza Flavio Tonetto - 4 maggio 2015 METODO SINERGIA: PASSIONE, COMPETENZA, CONCRETEZZA Gli obiettivi del convegno In questo

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

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

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