Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo sviluppo software

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo sviluppo software"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Ingegneria del Software Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo Anno Accademico 2011/2012 Candidato: Marcello Traiola matr. N I

2 II

3 Sommario Introduzione... 4 Capitolo 1 - La nascita dei metodi agili I principi dei metodi agili Attenzione ai requisiti! Scriviamo i requisiti... 9 Capitolo 2 - Tre metodi a confronto SCRUM Flow La specifica dei requisiti in SCRUM È fatto? Persone, non processi! Uno sguardo al processo di XP La specifica dei requisiti in XP The Planning Game L anima di XP L approccio di Crystal Crystal Clear Crystal Orange Crystal Orange/Web Capitolo 3 - Confronti e conclusioni Un analisi trasversale Supporto alla gestione del processo Guida pratica o concetti astratti? Approccio standard o adattivo? Quanta innovazione? Conclusioni Bibliografia Articoli scientifici Sitografia III

4 Introduzione Il rapido progresso tecnologico che ha caratterizzato gli ultimi decenni ha portato all introduzione dell informatica nella quasi totalità dei settori, che riguardano sia prodotti sia servizi. Un software avanzato che assista la produzione è, ormai, requisito fondamentale per ogni azienda che voglia creare prodotti di qualità con tempi e costi ridotti. Come sono sviluppati i software in grado di supportare in maniera adeguata la produzione? Le varie fasi del cosiddetto ciclo di vita del software sono oggetto di studio da molti anni e, secondo il contesto in cui vengono analizzate, presentano diverse peculiarità. La progettazione di un sistema critico per il controllo della stabilità di un velivolo, ad esempio, necessita che tutti i requisiti siano meticolosamente analizzati per verificare che le varie interazioni non compromettano la sicurezza; ciò richiede una lunga fase di analisi dei requisiti alla fine della quale si avrà un idea chiara e definitiva dei requisiti del sistema. «Quando questo approccio pesante [ ] [è] applicato a sistemi aziendali di piccole e medie dimensioni, l overhead richiesto [è] così alto che a volte [domina] il processo di sviluppo del sistema» [Sommerville 2007]. 4

5 Si comprende facilmente, infatti, come un azienda, influenzata dall andamento dei mercati e vincolata al rispetto di specifiche norme giuridiche, debba operare repentini cambi di rotta e prendere decisioni spesso in contrasto fra loro. Tutto ciò si riflette sul software. Un approccio come quello citato in precedenza necessita che i requisiti siano completamente definiti, cosa che avviene raramente in contesti del genere. Adottare soluzioni di sviluppo pesanti può portare a sviluppare software di qualità nei tempi stabiliti ma non garantisce che siano ancora utili. Nascono, quindi, i metodi agili. In questo testo ci si propone di esaminare il processo di analisi dei requisiti per alcuni fra i metodi agili più conosciuti e utilizzati. S introdurrà il concetto di metodo agile per poi proseguire con la presentazione di tre fra i metodi più famosi (SCRUM, extreme Programming e Crystal) ponendo l attenzione su come avviene la specifica dei requisiti. Infine si metteranno in luce pregi e difetti dei metodi descritti e si concluderà con un confronto. 5

6 Capitolo 1 La nascita dei metodi agili Negli anni 90 alcuni sviluppatori software proposero nuovi metodi di sviluppo che presero il nome di metodi agili. Il motivo principale per cui divenne necessario trovare un nuovo modo di fare software fu che, con i metodi tradizionali, «si impiegava più tempo per decidere come il sistema sarebbe stato sviluppato piuttosto che per lo sviluppo e il test del programma» [ Sommerville 2007]. L idea comune che unisce tutti i metodi agili è quella di sviluppo e consegna incrementale per cui durante la produzione si attraversano più di una volta tutte le fasi del ciclo di vita del software ( sviluppo ciclico ). Il software sarà sviluppato e consegnato per incrementi, ognuno dei quali implementerà una nuova funzionalità testata e pronta per essere commercializzata. In questo modo si 6

7 guadagna il feedback degli utenti così da comprendere più a fondo pregi e difetti del prodotto realizzato. 1.1 I principi dei metodi agili Individuals and interactions over processes and tools. Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Questi quattro punti rispecchiano ciò che i firmatari del manifesto agile (www.agilemanifesto.org) considerano importante nella creazione del software. Gli individui e le interazioni fra essi sono più importanti dei processi e degli strumenti poiché i progetti sono fondati sulle persone: queste devono essere motivate e devono lavorare in un ambiente che garantisca adeguato supporto. Si deve preferire un software funzionante a una documentazione esaustiva: quale metro migliore per misurare il progresso del rilascio frequente di software funzionante! Meglio collaborare col cliente piuttosto che negoziare un contratto: una conversazione face to face elimina fraintendimenti e rende tutti uniti per raggiungere gli obiettivi. Seguire un rigido piano rende meno flessibili, pertanto anche a stadi di sviluppo avanzati i cambiamenti vanno accolti per favorire la competitività del cliente. 7

8 1.2 Attenzione ai requisiti! Mentre in passato si dava molta importanza alla specifica minuziosa dei requisiti, l avvento dei metodi agili propone di prestare maggiore attenzione al fare piuttosto che al progettare. Questa proposta, nata per venire incontro a esigenze di sviluppo veloce del software, è stata fraintesa. La continua richiesta di programmi avanzati ed evoluti ha portato all eccesso opposto: «doing requirements takes time time that could be spent writing code and users often feel better if they think that people are working [ ] on their problems» [Ken Orr IEEE software 2004] ovvero: Analizzare requisiti prende tempo tempo che potrebbe essere speso scrivendo codice e gli utenti spesso si sentono più sereni pensando che le persone lavorino sui loro problemi. Si è giunti, dunque, a considerare quasi superflua l analisi dei requisiti sacrificando la comprensione del progetto cui si lavora in favore della sua rapida creazione. Ken Orr, nell articolo Agile Requirements: Opportunity or Oxymoron? pubblicato sulla rivista IEEE Software nel 2004, osserva come un analista, invece di assumere il ruolo passivo di scrivere ciò che gli utenti chiedono, dovrebbe aiutarli a inventare i requisiti. Infatti dice obiettivi e vincoli che il sistema deve rispettare spesso non sono chiari agli utenti, per cui c è bisogno che qualcuno li guidi attraverso il processo di analisi. Neil Maiden e Alexis Gizikis (Centre for HCI Design, City University, London) insieme a Suzanne Robertson (The Atlantic Systems Guild) nell articolo Provoking Creativity: Imagine What Your Requirements Could Be Like (IEEE Software, vol. 21, no. 5, 2004, pp ) riportano i risultati dell esperienza fatta lavorando con EUROCONTROL (European Organisation for the Safety of Air Navigation). L obiettivo era di progettare e implementare RESCUE (Requirements Engineeringwith Scenarios for User-centered Engineering), un processo per determinare i requisiti di interesse per gli utenti, applicandolo ad un sistema che fornisce assistenza computerizzata ai controllori di traffico aereo per risolvere potenziali conflitti tra velivoli (CORA-2). 8

9 Per stimolare la creatività i progettisti hanno coinvolto membri del team e stakeholders in quelli che chiamano workshop. Durante il primo di questi sono stati invitati esperti di design tessile e compositori musicali per incoraggiare confronti e analogie tra i due settori e CORA-2. Durante il secondo un esperto fabbricante di giochi Lego ha introdotto oggetti a caso durante discussioni su scenari di risoluzione dei conflitti tra velivoli allo scopo di provocare pensiero creativo. Per il terzo, infine, è stato invitato un fusion chef a discutere il legame fra ingredienti non convenzionali facendoli assaggiare; lo chef ha inoltre dato dimostrazione della cucina fusion preparando un pranzo che ha messo in luce le differenze tra gli ingredienti ma anche la loro complementarietà. Ogni workshop, inoltre, partiva con attività mirate a creare il giusto ambiente per sviluppare pensiero creativo; tra queste le più singolari: palloncini per incoraggiare al gioco e all interazione, shouting sessions per contrastare inibizioni e incoraggiare il lavoro di gruppo, ascolto di musica rilassante. Da questo studio sono emerse le grandi difficoltà degli utenti nel definire i requisiti per i propri software e il ruolo centrale che gli analisti dovrebbero avere nel guidarli attraverso il processo. 1.3 Scriviamo i requisiti Come abbiamo finora descritto, le tecniche agili hanno avuto un impatto molto forte sul processo di definizione dei requisiti. Ora occupiamoci di comprendere le novità che sono state introdotte nella documentazione dei requisiti. Gli stakeholder scrivono le cosiddette storie utente e ciò spesso accade durante i workshop. Ogni storia utente Storie Utente [Maiden and Jones, IEEE Software, vol.27 no.3, 2010, pp ] è scritta su una cartolina di 9

10 dimensioni contenute (3x5 pollici) poiché semplicità e brevità sono caratteristiche precipue delle storie utente. Ognuna descrive un requisito in maniera semplice dal punto di vista dell utente senza specificare troppi particolari. Ciò lascia spazio alla comunicazione faccia a faccia durante la quale si definiscono meglio gli obiettivi di ogni requisito. Ogni progetto genera molte storie utente in modo che sia semplice selezionarle e gestire i requisiti da implementare. Lan Cao e Balasubramaniam Ramesh nello studio condotto sull utilizzo dei metodi agili nella specifica dei requisiti (RE, requirements engineering ), hanno identificato sette pratiche di RE utilizzate dalle 16 organizzazioni prese in esame [IEEE Software vol.25 no.1 January/February 2008, pp , Agile Requirements Engineering Practices: An Empirical Study ]. Ognuna di queste presenta lati positivi e negativi: Comunicazione faccia a faccia invece di specifiche scritte o Benefits: I clienti guidano il progetto in direzioni inaspettate quando le loro richieste mutano in seguito a cambi di environment. Il tempo sprecato per consultare la documentazione, ora superflua a causa dei cambiamenti ricorrenti, è utilizzato in maniera più produttiva. o Challenges: È difficile che il cliente sia sempre disponibile per un incontro e ciò pone dei rischi come la possibilità di avere requisiti non ben sviluppati o, addirittura, sbagliati. L effettiva comunicazione dipende, oltre che dalla disponibilità, anche della fiducia reciproca tra team e cliente. Infine se i clienti interessati al prodotto sono più di uno non è facile raggiungere compromessi che mettano tutti d accordo in cicli di sviluppo brevi. Specifica dei requisiti iterativa o Benefits: «I think the difference for me came in the quality of the software [and] the stability of the software. [ ] I think the agile [RE] lent itself to [ ] a very robust rich implementation of features [ ] [for] the first time»: le parole di un cliente, che confronta l esperienza agile con quella 10

11 tradizionale, mettono in luce il rapporto di fiducia tra team e cliente che nasce dai continui incontri e il conseguente piacere di quest ultimo nel vedere soddisfatte le proprie aspettative. I requisiti diventano più chiari e comprensibili grazie all immediato coinvolgimento del cliente quando necessario. o Challenges: Complessità nello stimare costi e tempi: ottenere supporto manageriale in progetti di questo tipo non è semplice. La poca documentazione prodotta può causare vari problemi come la difficoltà di migliorare il software e coinvolgere nuovi membri nel team. Requisiti non funzionali sono spesso mal definiti poiché l attenzione è focalizzata sulle funzionalità principali e requisiti come scalabilità, manutenibilità, portabilità, sicurezza o performance sono ignorati. Frequenti cambi di priorità dei requisiti o Benefits: Siccome nella RE agile la priorità dei requisiti è scelta in base alle esigenze di mercato come sono intese dal cliente, la partecipazione di quest ultimo alla realizzazione fornisce in ogni ciclo di sviluppo motivazioni, di tipo economico, per l implementazione di un requisito piuttosto che di un altro. o Challenges: D altro canto gestire la priorità dei requisiti guardando al mercato come unico obiettivo può causare problemi riguardanti requisiti non funzionali come stabilità, sicurezza, efficienza, scalabilità, etc. La continua pianificazione cambia il modo di gestire i requisiti o Benefits: Il continuo confronto tra team e cliente fornisce maggior consapevolezza riguardo al lavoro svolto poiché in ogni incontro l attività di pianificazione assume ruolo fondamentale. Per questo motivo la maggior parte dei cambiamenti richiesti sono «usually more a case of tweaks spelling, little graphical things for example, color, positioning». 11

12 o Challenges: Siccome l architettura scelta durante le prime fasi del processo produttivo diventa inadeguata in alcuni casi con il cambiare dei requisiti, progettarne una nuova aggiunge costi al progetto. Spesso neanche il refactoring, che semplifica il codice senza compromettere le funzionalità, riesce a porre rimedio a problemi di architettura. Uso di prototipi o Benefits: Invece di perdere tempo a scrivere documentazione dettagliata si mostra al cliente il lavoro svolto per discuterne la validità. o Challenges: È complicato manutenere e aggiornare i prototipi e causa problemi con requisiti come scalabilità, sicurezza e robustezza. Sviluppo guidato dai test (TDD). o Benefits: Creare dei test prima di creare il codice che li supererà «allows you to be more adventurous in terms of making changes and trying out ideas» poiché si ha un feedback immediato del lavoro svolto. o Challenges: Gli sviluppatori non sono abituati a scrivere i test prima del codice. Sono necessarie una profonda comprensione dei requisiti e una collaborazione intensiva tra sviluppatori e clienti. Utilizzo review meetings e acceptance tests o Benefits: I review meeting riportano prima di tutto i progressi del progetto al cliente e agli stakeholder e danno la possibilità di capire se il progetto procede verso l obiettivo desiderato. Inoltre fiducia e confidenza tra cliente e team si fortificano. o Challenges: Spesso è difficile implementare gli acceptance test a causa della difficoltà di far riferimento ai clienti che li hanno sviluppati. Emerge, dunque, che la differenza fondamentale tra RE tradizionale e RE agile è che quest ultima sfrutta un approccio iterativo per scoprire i requisiti e non segue un rigido piano di sviluppo. Ciò è dovuto al fatto che, in alcuni ambienti, ottenere 12

13 specifiche molto precise è praticamente impossibile oppure addirittura inutile in quanto è probabile che cambino. Osservando i risultati dello studio di Cao e Ramesh si capisce come la novità più apprezzata in ambienti del genere sia l intensiva comunicazione che porta il team a comprendere i desideri del cliente e rende lo sviluppo più dinamico e adattabile. 13

14 Capitolo 2 Tre metodi a confronto In questo capitolo si cercherà di analizzare, per ogni metodologia agile proposta, il processo di specifica dei requisiti al fine di fornire un punto di vista utile, nel capitolo successivo, ad analizzare differenze e somiglianze e a comprendere in quali situazioni una metodologia possa essere più utile rispetto a un altra. 2.1 SCRUM Flow Prima di parlare del processo di specifica dei requisiti in SCRUM occupiamoci di dare un quadro generale del processo e delle persone che portano al rilascio del software. Partiamo analizzando lo SCRUM Team composto da Product Owner, Team e SCRUM Master. o Il Product Owner è una persona che rappresenta il committente. È responsabile della gestione del Product Backlog e ha il compito di massimizzare il valore del lavoro svolto dal team. Le sue decisioni devono essere rispettate affinché il suo lavoro sia efficace. o Il Team è composto di più persone (in genere tra 3 e 9) che lavorano per produrre un incremento del prodotto da consegnare alla fine di uno sprint. Il 14

15 team è organizzato in maniera autonoma ed è cross-funzionale. Ogni membro ha le stesse responsabilità degli altri a prescindere dal ruolo svolto. o Lo SCRUM Master ha, da una parte, il ruolo di leader per il team e, dall altra, d intermediario tra il team e coloro che non ne fanno parte. Ha il compito di verificare che il team comprenda e applichi le regole di SCRUM e quello di riconoscere quali interazioni tra il team e gli stakeholder sono utili e quali no. Lo Sprint è considerato il cuore di SCRUM. È un periodo durante il quale il team produce un incremento del prodotto secondo le priorità imposte dal Product Backlog allo scopo di rilasciare sul mercato funzionalità complete e testate. Lo Sprint consta, oltre che di quella di sviluppo, di più fasi: o Sprint Planning Meeting: riunione durante la quale sono pianificate le attività da svolgere durante lo Sprint. Partecipa l intero SCRUM Team. La prima delle due fasi dell incontro è incentrata su cosa sarà fatto durante lo Sprint: il Product Owner presenta i punti del Product Backlog partendo da quelli a priorità maggiore e, in base anche all ultimo incremento e alle performance precedenti del Team, si definisce l Obiettivo di Sprint (o Sprint Goal) che sarà perseguito. Il numero di punti del Product Backlog che saranno considerati nello Sprint Goal e, quindi, implementati è deciso esclusivamente dal Team poiché nessuno conosce meglio le sue potenzialità. La seconda fase della riunione è incentrata sul come si porterà a termine il lavoro in programma. In questa fase nasce lo Sprint Backlog fatto dalle voci selezionate dal Product Backlog e dal piano per la consegna. Si progetta il lavoro necessario all implementazione dei requisiti scelti e, se risulta troppo o troppo poco, si possono ridiscutere con il Product Owner le voci selezionate dal Product Backlog. 15

16 La durata di un Meeting è di otto ore per uno Sprint di un mese. Se lo Sprint dura meno, si avrà una riduzione proporzionata della durata del Meeting. o Daily Scrum: Riunione giornaliera di 15 minuti (ogni giorno nello stesso posto e alla stessa ora) utile al Team di Sviluppo per definire e sincronizzare le attività della giornata in base al lavoro svolto il giorno precedente. Durante la riunione ci si accerta che il lavoro svolto sia sempre in linea con lo Sprint Goal. Lo SCRUM Master assicura e disciplina lo svolgimento della riunione che è condotta, però, esclusivamente dal Team. L obiettivo principale della riunione, in fondo, è quello di migliorare le comunicazioni all interno del team per eliminare ostacoli come incomprensioni o malintesi nel pieno rispetto delle metodologie agili. o Sprint Review: Incontro che avviene al termine di uno Sprint per esaminare l incremento prodotto e modificare, se necessario, il Product Backlog. Prendono parte alla riunione anche gli stakeholder. Si tratta di un colloquio informale atto a suscitare i commenti dei partecipanti e a spronare la collaborazione. Durante lo svolgimento il Team riporta l evoluzione dello Sprint evidenziando i problemi incontrati e le soluzioni trovate. In base al lavoro prodotto, il Product Owner fa delle stime sul tempo ancora necessario e discute col Team di eventuali accorgimenti da fare. Il risultato è un Product Backlog riesaminato e aggiornato. La durata dell incontro è di quattro ore per uno Sprint di un mese. Se lo Sprint dura meno, si avrà una riduzione proporzionata della durata dell incontro. o Sprint Retrospective: È una riunione di tre ore (dopo uno Sprint di un mese) che riguarda esclusivamente il Team SCRUM. Lo scopo di tale incontro è far si che il Team guardi a se stesso in modo critico e adatti il proprio atteggiamento secondo i problemi che emergono per trovare soluzioni in maniera più 16

17 semplice. Lo SCRUM Master incoraggia tale attività e invita il Team a individuare pratiche per rendere più efficace e divertente lo Sprint successivo. SCRUM Flow [Ken Schwaber, Agile Project Management with Scrum, Microsoft Press 2004] La specifica dei requisiti in SCRUM Quello di Product Backlog è il concetto intorno a quale gira il processo di specifica dei requisiti in un ambiente di che sfrutta l utilizzo di SCRUM. Il termine indica la lista di requisiti ottenuta a valle di una discussione tra il team di sviluppo e il cosiddetto Product Owner, che rappresenta il soggetto committente ed è l unico responsabile del Product Backlog. La caratteristica precipua del Product Backlog è di non essere mai completo ma, piuttosto, sempre in continua evoluzione in base alle modifiche che i requisiti subiscono con l avanzare del progetto e alla priorità che essi assumono. Ciò che si trova alla base di questa caratteristica è la consapevolezza che lo sviluppo del software in sé porta alla luce problematiche non prevedibili nell analisi iniziale, cosa che compromette anche le stime dei tempi di sviluppo più accurate. 17

18 Gli elementi presenti nel Product Backlog sono spesso ordinati per priorità, rischio, valore, necessità; in cima alla lista, in genere, si trovano gli elementi più discussi dal team, quindi più conosciuti e consolidati, che saranno trattati per primi. Al concetto di Product Backlog è strettamente legato quello di Sprint. Questo termine indica la finestra temporale alla fine della quale sarà rilasciato un incremento del prodotto potenzialmente utilizzabile che implementa parte delle funzionalità. La durata di uno Sprint è molto limitata (in genere massimo un mese) in accordo al principio di rilascio graduale che contraddistingue le metodologie agili. In questo modo ogni funzionalità realizzata è testata a fondo prima del rilascio per garantire che soddisfi le specifiche richieste. Al termine di ogni Sprint ha luogo una riunione ( Sprint review ) in cui si discute il lavoro fatto durante lo Sprint appena concluso e si concorda il lavoro che sarà fatto durante il successivo. Il Product Backlog in questa fase si evolve in accordo con quanto emerso durante lo Sprint. Alla fine di questa fase, dunque, si ottiene una lista aggiornata dei requisiti che il software deve soddisfare e si conosce quale sarà il lavoro da svolgere durante lo Sprint che sta per cominciare È fatto? Presupposto fondamentale per la buona riuscita dell analisi dei requisiti e per un buon test delle funzionalità implementate è la condivisione del concetto astratto di fatto (cfr. done in inglese). Com è naturale, la definizione di un concetto astratto è difficilmente condivisa da tutti, motivo per il quale concetti espressi in poche parole, magari scritte, spesso sono confusi con altri secondo la personale interpretazione. Citando Mike Cohn: «Written words are misleading - they look more precise than they are» [Cohn 2009] ovvero Le parole scritte sono fuorvianti sembrano più precise di quanto non lo siano. Definire, dunque, un interpretazione comune del concetto di fatto giova enormemente al processo di sviluppo giacché porta i membri del team a perseguire un obiettivo comune e a lavorare in armonia giovandosi ognuno del lavoro degli altri. 18

19 Si può facilmente capire, quindi, come diverse interpretazioni del concetto di completezza incidano sulla stima dei tempi necessari allo sviluppo di una funzionalità e, di conseguenza, sulla scelta di quanti e quali elementi del Product Backlog trattare in uno Sprint Persone, non processi! Il processo di produzione tradizionale è diviso in fasi ben distinte sulle quali è difficile ritornare una volta concluse. Per quanto riguarda la specifica dei requisiti quest approccio produce un documento preciso e puntuale in cui le richieste del cliente hanno una forma ben definita e vanno a tutti i costi rispettate. Ciò porta gli sviluppatori a sentirsi costretti a implementare ciò che il documento prescrive e non a condividere gli obiettivi che tale documento hanno prodotto. SCRUM pone l attenzione più sulle persone che sul processo di produzione giacché quest ultimo dipende dalle persone che lo intraprendono. Prendere in considerazione un processo produttivo in maniera assoluta porta inevitabilmente a un calo della qualità del prodotto o, quantomeno, ad avere tempi di produzione più lunghi. Riportiamo le parole di Mike Cohn per comprendere meglio il concetto appena espresso: One of the goals of shifting to Scrum is to get the whole team working together toward the goal of delivering a great product. We want to strip our development process of bad habits that work against this goal. Written documents create sequential hand-offs, which deprive the team of a unity of purpose. One person (or group) defines the product; another group builds it. Two-way communication is discouraged. Through the written document, one team member is saying, "Here's what to do," and others are expected to do it. This type of master-and-servant relationship is unlikely to create strong feelings of engagement on the part of the servants. Rather than feeling responsible for the success of the product, they feel responsible for doing what is described in the document. Discussions have the 19

20 opposite effect: Whole team discussions lead to greater buy-in by all team members [Cohn 2009]. 2.2 Uno sguardo al processo di XP Diamo ora un rapido sguardo all intero processo produttivo di extreme Programming (XP d ora in poi) in cui la specifica dei requisiti s innesta. Oltre alle fasi di Esplorazione e Pianificazione racchiuse nel Planning Game che vedremo nei prossimi paragrafi, il processo XP consta di altre quattro fasi: o Iterazioni verso il primo rilascio: fase caratterizzata da più iterazioni che portano alla prima versione del software pronta per essere utilizzata. Sono selezionate le storie e sono prodotti test funzionali per ogni iterazione. o Fase di produzione: durante la produzione potrebbe presentarsi la necessità di ridurre il tempo dedicato a ogni iterazione, di creare test prestazionali e di cambiare storie (dopo una discussione col Cliente). o Manutenzione: fase in cui il processo si trova per la maggior parte della sua vita; mentre il sistema è in esecuzione, si sviluppano nuove funzioni in modo da non interrompere l erogazione dei servizi implementati e aggiungerne di nuovi. o Morte: questa fase terminale sopraggiunge quando i clienti non sono più in grado di produrre storie oppure quando il sistema non è più in grado di soddisfare le necessità del cliente. È la fase in cui bisogna necessariamente produrre documentazione. 20

21 2.2.1 La specifica dei requisiti in XP «We will plan by quickly making an overall plan, then refining it further and further on shorter and shorter time horizons years, months, weeks, days. We will make the plan quickly and cheaply, so there will be little inertia when we must change it» [Beck 1999]. La specifica dei requisiti in XP è un processo che avviene durante la fase individuata dal termine The Planning Game. Questa pratica si basa su alcuni principi cardine: Pianificare in modo dettagliato esclusivamente il prossimo rilascio: si può pensare alle iterazioni successive ma assolutamente non nei dettagli. Assumere responsabilità, non darle: il manager non può assegnare il lavoro, è ogni membro del team che deve decidere cosa può fare. La stima dei tempi di realizzazione deve essere fatta da chi realizza. Ignorare le dipendenze tra le parti del progetto: progettare come se le parti potessero cambiare in ogni istante. Pianificazione orientata alle priorità: il cliente non ha bisogno di molti dettagli per fissare le priorità. 21

22 2.2.2 The Planning Game L obiettivo della pianificazione in XP è di eliminare imbarazzi e screzi tra clienti e sviluppatori e incoraggiare la comunicazione. Ciò è conseguenza del fatto che non esistono regole, per quanto flessibili, che possano eliminare le emozioni dalle persone. È importante che esistano regole al fine di ricordare come ci si dovrebbe comportare e di fornire un riferimento comune nel caso in cui le cose non procedano per il giusto verso. Ognuna delle due parti, clienti e sviluppatori, deve rispettare l altra e solo in un ambiente di fiducia si può lavorare in maniera serena. È necessario, quindi, avere delle regole che suggeriscano come impostare i rapporti, ma è essenziale che rimangano dei suggerimenti in modo che, se il rapporto diventa ben saldo, si possano anche modificare o rimuovere. o Obiettivo: obiettivo del gioco è massimizzare il valore del software prodotto. Dal valore del software si deve stimare il costo dello sviluppo e i rischi che si corrono. o Strategia: Il team tende a investire meno possibile per mettere in produzione le funzionalità principali il più velocemente possibile con strategie atte a ridurre i rischi. Quando al cliente diviene chiaro quali sono le funzionalità più importanti il team può immediatamente metterle in produzione. o I pezzi del gioco: I pezzi del plannig game sono le story card (in figura). Ogni storia descrive, nel modo più semplice possibile, una funzionalità che il sistema dovrebbe implementare. Seguendo questa pratica si avrà un inquadramento generale della questione e non si creeranno rigidi schemi da seguire. 22

23 Story Card [Kent Beck, 1999, Extreme Programming Explained: Embrace Change ] o I giocatori: Come si è già intuito, devono esserci due giocatori, il Cliente (decide come il sistema deve essere) e lo Sviluppo (realizza il sistema). o Le mosse: il gioco ha fondamentalmente tre fasi Esplorazione: in questa fase i partecipanti si rendono conto di ciò che il sistema dovrebbe fare. Il Cliente scrive una storia descrivendo cosa dovrebbe fare il sistema, lo Sviluppo stima il tempo d implementazione. Nel caso la stima non sia possibile o ci siano parti più importanti rispetto a altre, si divide la storia in più parti. Impegno: il Cliente propone una data di rilascio e lo Sviluppo s impegna a rispettarla. In questa fase il Cliente organizza le card per valore, lo Sviluppo le organizza per rischio e comunica il tempo necessario per realizzarle. Alla luce dei risultati, poi, il Cliente sceglie le card da includere nell iterazione. Aggiornamento: all inizio di ogni iterazione il Cliente sceglie le storie da implementare che formino un sistema funzionante. Se lo Sviluppo si accorge di essersi sopravvalutato può chiedere al Cliente di rivedere le storie da implementare alla luce delle nuove 23

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

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

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

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

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

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

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

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

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

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

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

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

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

Coaching. Nicola Moretto

Coaching. Nicola Moretto nicola.moretto@xpeppers.com XP Coach Coach Tecnico Scrum Master Coach Sistemico Evolutivo Coach Ontologico Trasformazionale Agile Coach Coach Puro Scrum Master Uno Scrum Master: Rimuove le barriere.

Dettagli

LA SICUREZZA E IMPORTANTE

LA SICUREZZA E IMPORTANTE DISC PROFILO VERDE INTRODUZIONE Le persone con un alto profilo comportamentale VERDE preferiscono lavorare all interno di strutture esistenti e collaborare con gli altri. Il VERDE vuole sentirsi sicuro

Dettagli

Agile in tough economic times. Agile in tough. Slide 1 30 April 2009

Agile in tough economic times. Agile in tough. Slide 1 30 April 2009 Slide 1 Indice Storia Agile di una startup nel nostro progetto Qual e il valore aggiunto di Agile nei periodi di incertezza Conclusioni Slide 2 Non disclosure agreement Ho firmato un NDA che non mi permette

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

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione.

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. La Compagnia Della Rinascita PEOPLE CARE Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. PEOPLE CARE Un equipe di professionisti che si

Dettagli

L ENTUSIASMO E IMPORTANTE

L ENTUSIASMO E IMPORTANTE DISC PROFILO GIALLO INTRODUZIONE Le persone con un alto profilo comportamentale GIALLO influenzano il loro ambiente essendo socievoli, persuasivi e convincenti al punto da influenzare e ispirare gli altri.

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

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

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

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

Customer satisfaction

Customer satisfaction [moduli operativi di formazione] Customer satisfaction Soddisfare Migliorare Continuare a soddisfare CUSTOMER SATISFACTION Tutte le aziende dipendono dai propri clienti ed è indispensabile agire per capire

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

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

Dettagli

10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi. Report riservato a Manager, Imprenditori e Professionisti

10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi. Report riservato a Manager, Imprenditori e Professionisti 10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi Report riservato a Manager, Imprenditori e Professionisti Nel 2013 hanno chiuso in Italia oltre 50.000 aziende, con un aumento di oltre

Dettagli

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO Report globale e suggerimenti Gennaio 2013 Autore: Filigree Consulting Promosso da: SMART Technologies Executive

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

GUIDA VELOCE PER TRAINER

GUIDA VELOCE PER TRAINER GUIDA VELOCE ~ 6 ~ GUIDA VELOCE PER TRAINER Perché usare il toolkit di EMPLOY? In quanto membro del personale docente, consulente di carriera, addetto al servizio per l impiego o chiunque interessato ad

Dettagli

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

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

Dettagli

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

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

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

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Il Working Partnership

Il Working Partnership Il Working Partnership Il Working Partnership è uno strumento/risorsa per tutti coloro che sono interessati allo sviluppo e al miglioramento del lavoro di partnership. Lo strumento deriva da un precedente

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

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

I METODI DEL MIGLIORAMENTO

I METODI DEL MIGLIORAMENTO I METODI DEL MIGLIORAMENTO 1 Le macro-tipologie di intervento di miglioramento: Su base giornaliera: è un intervento che può essere applicato quando i processi rispondono agli obiettivi aziendali, ma possono

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

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

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

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business 2 La guida CRM per eliminare le incertezze: prendete il controllo del vostro business (2 - migliorate la vostra credibilità: i 5 passi per dimostrare l efficacia del Marketing) Pagina 1 di 9 SOMMARIO PREMESSA...

Dettagli

Le undici competenze chiave del coaching secondo ICF

Le undici competenze chiave del coaching secondo ICF Le undici competenze chiave del coaching secondo ICF Le seguenti undici competenze chiave del coaching sono state sviluppate per fornire una maggiore comprensione rispetto alle capacità ed agli approcci

Dettagli

COMPETENZE DI BASE ICF Aggiornamento 2009

COMPETENZE DI BASE ICF Aggiornamento 2009 COMPETENZE DI BASE ICF Aggiornamento 2009 Le 11 competenze di base del coaching sono state sviluppate per permettere una migliore comprensione delle competenze e degli approcci utilizzati nell ambito della

Dettagli

Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari

Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari Definizione di progetto Cos è un progetto Progetto si definisce, di regola, uno sforzo complesso di durata solitamente

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

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

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

Dettagli

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

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

Dettagli

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

I N D I C E LE PERSONE SONO L ELEMENTO CHIAVE PER RAGGIUNGERE I RISULTATI

I N D I C E LE PERSONE SONO L ELEMENTO CHIAVE PER RAGGIUNGERE I RISULTATI COACHING LE PERSONE SONO L ELEMENTO CHIAVE PER RAGGIUNGERE I RISULTATI I N D I C E 1 [CHE COSA E IL COACHING] 2 [UN OPPORTUNITA DI CRESCITA PER L AZIENDA] 3 [ COME SI SVOLGE UN INTERVENTO DI COACHING ]

Dettagli

Judgment. Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement.

Judgment. Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement. Judgment Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement.com 2014 Hogan Assessment Systems PERSONALITÀ E DECISIONI I problemi

Dettagli

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI 1. Lavorare per progetti La parola, oltre ad avere il significato del lessico comune, significa anche approccio manageriale, soprattutto da quando

Dettagli

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System)

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) Giuseppe Santucci Qualità nella Produzione del Software 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) 02SQAS.1 Peculiarità del SW XXX warrants that the media (!) on which

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

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 del gruppo di lavoro: motivazione e coaching

Gestione del gruppo di lavoro: motivazione e coaching Gestione del gruppo di lavoro: motivazione e coaching Il team Un gruppo di persone che: condividono uno scopo, hanno un obiettivo in comune collaborano, moltiplicando le loro risorse condividono i vantaggi

Dettagli

I processi aziendali e l industria della cornice di legno.

I processi aziendali e l industria della cornice di legno. I processi aziendali e l industria della cornice di legno. Productio Flow può essere classificato come un sistema software progettato ad hoc sulle esigenze gestionali dell industria della cornice di legno

Dettagli

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Giuseppe Chiazzese CNR - Istituto per le tecnologie didattiche Modulo: Introduzione agli strumenti web per

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

Premessa... 1. Vantaggi di un sistema ERP... 2. Fasi del processo... 3. Zone di rischio... 4

Premessa... 1. Vantaggi di un sistema ERP... 2. Fasi del processo... 3. Zone di rischio... 4 Sommario Premessa... 1 Vantaggi di un sistema ERP... 2 Fasi del processo... 3 Zone di rischio... 4 Premessa Le tecnologie informatiche hanno rivoluzionato da tempo il modo in cui lavorano le aziende e

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

Obiettivo Principale: Spiegare come la stessa cosa possa essere realizzata in molti modi diversi e come, a volte, ci siano modi migliori di altri.

Obiettivo Principale: Spiegare come la stessa cosa possa essere realizzata in molti modi diversi e come, a volte, ci siano modi migliori di altri. 6 LEZIONE: Algoritmi Tempo della lezione: 45-60 Minuti. Tempo di preparazione: 10-25 Minuti (a seconda che tu abbia dei Tangram disponibili o debba tagliarli a mano) Obiettivo Principale: Spiegare come

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

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

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

Dettagli

Obiettivo Principale: Aiutare gli studenti a capire cos è la programmazione

Obiettivo Principale: Aiutare gli studenti a capire cos è la programmazione 4 LEZIONE: Programmazione su Carta a Quadretti Tempo della lezione: 45-60 Minuti. Tempo di preparazione: 10 Minuti Obiettivo Principale: Aiutare gli studenti a capire cos è la programmazione SOMMARIO:

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

Pure Performance Una direzione chiara per raggiungere i nostri obiettivi

Pure Performance Una direzione chiara per raggiungere i nostri obiettivi Pure Performance Una direzione chiara per raggiungere i nostri obiettivi 2 Pure Performance La nostra Cultura Alfa Laval è un azienda focalizzata sul cliente e quindi sul prodotto con una forte cultura

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

Valori e Principi Rieter

Valori e Principi Rieter Valori e Principi Rieter Comfort thanks to Rieter Delight your customers Enjoy your work Fight for profits Rieter is a publicly-listed Swiss industrial group providing innovative solutions to the global

Dettagli

PMO: così fanno le grandi aziende

PMO: così fanno le grandi aziende PMO: così fanno le grandi aziende Tutte le grandi aziende hanno al loro interno un PMO - Project Management Office che si occupa di coordinare tutti i progetti e i programmi aziendali. In Italia il project

Dettagli

Team Building e Volontariato d impresa

Team Building e Volontariato d impresa Team Building e Volontariato d impresa LE MALATTIE RARE OGNI MINUT0 NEL MONDO NASCONO 10 BAMBINI COME TOMMASO, AFFETTI DA UNA MALATTIA GENETICA RARA. La Formazione di Valore produce VALORE Rebis e Zeta

Dettagli

Sommario. DOCUMENTO RISERVATO AD USO INTERNO Pagina 2 di 10

Sommario. DOCUMENTO RISERVATO AD USO INTERNO Pagina 2 di 10 Piano di valutazione Horsa Anno 2013 Sommario Perché Horsa introduce un Piano di Valutazione... 3 I destinatari del Piano di Valutazione... 4 I criteri di acquisizione dei Punti... 4 Costi standard di

Dettagli

Principi e requisiti di base del Risk Management. Obiettivi, standard e framework di riferimento

Principi e requisiti di base del Risk Management. Obiettivi, standard e framework di riferimento Innovazione per la Pubblica Amministrazione Principi e requisiti di base del Risk Management. Obiettivi, standard e framework di riferimento Fabio Monteduro CISPA-Università di Roma Tor Vergata fabio.monteduro@uniroma2.it

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

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

Agili, snelli e scattanti!

Agili, snelli e scattanti! Agili, snelli e scattanti! Dipartimento di Scienze Odontostomatologiche 4 Giugno 2013 Emiliano Soldi PMP, PMI-ACP, CSM Agile Practice Leader & Coach http://www.emilianosoldipmp.info @EmilianoSoldi Agile

Dettagli

CRM E GESTIONE DEL CLIENTE

CRM E GESTIONE DEL CLIENTE CRM E GESTIONE DEL CLIENTE La concorrenza è così forte che la sola fonte di vantaggio competitivo risiede nella creazione di un valore superiore per i clienti, attraverso un investimento elevato di risorse

Dettagli

Questionario Service Standard CoC CTCY. Familiari

Questionario Service Standard CoC CTCY. Familiari Questionario Service Standard CoC CTCY Familiari QUESTIONARIO SUGLI STANDARD DELLE COMUNITA PER MINORI RIVOLTO AI FAMILIARI DEGLI UTENTI OSPITI Simone Bruschetta Catania, 2012 Versione ridotta per i familiari

Dettagli

Premessa... 1. Fasi del processo... 3. Zone di rischio... 4

Premessa... 1. Fasi del processo... 3. Zone di rischio... 4 Sommario Premessa... 1 Fasi del processo... 3 Zone di rischio... 4 Premessa Le tecnologie informatiche hanno rivoluzionato da tempo il modo in cui lavorano le aziende e le organizzazioni in genere. Gestire

Dettagli

VALUTAZIONE RIFERIMENTI TEORICI: M. COMOGLIO C.A. TOMLINSON

VALUTAZIONE RIFERIMENTI TEORICI: M. COMOGLIO C.A. TOMLINSON LA VALUTAZIONE RIFERIMENTI TEORICI: M. COMOGLIO C.A. TOMLINSON Attivazione struttura cooperativa ALZATI E CONDIVIDI QUALI SONO I PROBLEMI CHE INCONTRO NELLA VALUTAZIONE? CRITICA ALLA VALUTAZIONE TRADIZIONALE

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

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

Introduzione. Articolazione della dispensa. Il sistema del controllo di gestione. Introduzione. Controllo di Gestione

Introduzione. Articolazione della dispensa. Il sistema del controllo di gestione. Introduzione. Controllo di Gestione Introduzione Perché il controllo di gestione? L azienda, come tutte le altre organizzazioni, è un sistema che è rivolto alla trasformazione di input (risorse tecniche, finanziarie e umane) in output (risultati

Dettagli

IPMA DELTA l Assessment in project management p e r l o r g a n i z z a z i o n e a z i e n d a l e

IPMA DELTA l Assessment in project management p e r l o r g a n i z z a z i o n e a z i e n d a l e IPMA DELTA l in project management p e r l o r g a n i z z a z i o n e a z i e n d a l e UNA UNA VISIONE A 360 INDIPENDENTE AL 100% P E R U N A MIG LIO R E C O M P ETITIVITÀ a product of L EFFETTO DELTA.

Dettagli

LABORATORIO 30 aprile. Date

LABORATORIO 30 aprile. Date LABORATORIO 30 aprile Date Laboratorio E un gioco che si chiama XP game materiale, manuali istruttori, etc... sono tutti disponibili online (vi darò i riferimenti) centrato su spiegare alcuni concetti

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

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO QUESTIONARIO SUGLI STILI DI APPRENDIMENTO Le seguenti affermazioni descrivono alcune abitudini di studio e modi di imparare. Decidi in quale misura ogni affermazione si applica nel tuo caso: metti una

Dettagli

Lo stile di comando. teoria degli stili comportamentali. teoria contingente. teorie di processo. Corso di E. A. 1

Lo stile di comando. teoria degli stili comportamentali. teoria contingente. teorie di processo. Corso di E. A. 1 Lo stile di comando teoria degli stili comportamentali teoria contingente teorie di processo Corso di E. A. 1 Lo stile di comando La leadership può essere definita come il processo attraverso il quale

Dettagli

Perché una technology agency.

Perché una technology agency. Perché una technology agency. Creatività Strategia UX design Seo WEB PROJECT Partner layer CMS abstract Un progetto web moderno è composto da elementi diversi come creatività, strategia e business che

Dettagli

Come passare dal budget tradizionale al piano d azione annuale: il caso GDO

Come passare dal budget tradizionale al piano d azione annuale: il caso GDO Come passare dal budget tradizionale al piano d azione annuale: il caso GDO di Massimo Lazzari e Davide Mondaini (*) L evoluzione rapida e irreversibile dei contesti di riferimento in cui le aziende si

Dettagli

Business Analysis. Emiliano Castellina Senior Consultant

Business Analysis. Emiliano Castellina Senior Consultant Business Analysis Emiliano Castellina Senior Consultant Presentazione Reply è una società di Consulenza, System Integration e Application Management. Reply unisce competenze verticali di mercato, con il

Dettagli

TECNICHE DI VALUTAZIONE DEL RISCHIO

TECNICHE DI VALUTAZIONE DEL RISCHIO Per conto di AICQ CN 1 - Autore Giovanni Mattana - Consigliere di Giunta AICQ CN Presidente della Commissione UNI per i Sistemi di Qualità La norma è intesa come un supporto per la Iso 31000 e fornisce

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

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

STAKEHOLDER ENGAGEMENT

STAKEHOLDER ENGAGEMENT STAKEHOLDER ENGAGEMENT IN BREVE E-quality Italia S.r.l. Via Mosca 52-00142 Roma T 0692963493, info@equality-italia.it, http://www.equality-italia.it Indice 1. Il problema 3 2. Stakeholder Engagement in

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

1. Il ruolo della pianificazione nella gestione del progetto

1. Il ruolo della pianificazione nella gestione del progetto 11 1. Il ruolo della pianificazione nella gestione del progetto Poiché ciascun progetto è un processo complesso ed esclusivo, una pianificazione organica ed accurata è indispensabile al fine di perseguire

Dettagli

Per costruire e migliorare il rapporto di collaborazione Scuola /Famiglia

Per costruire e migliorare il rapporto di collaborazione Scuola /Famiglia Istituto Comprensivo - Monte Urano Via Vittorio Alfieri 1 - Monte Urano - prov. Ascoli Piceno - cap.63015 telefono 0734/840605 Fax 0734/840880 Per costruire e migliorare il rapporto di collaborazione Scuola

Dettagli

LO START UP D IMPRESA INNOVATIVA Vantaggi, agevolazioni fiscali, finanziamenti e incentivi della Regione Toscana. Giovedì 26 novembre 2015

LO START UP D IMPRESA INNOVATIVA Vantaggi, agevolazioni fiscali, finanziamenti e incentivi della Regione Toscana. Giovedì 26 novembre 2015 LO START UP D IMPRESA INNOVATIVA Vantaggi, agevolazioni fiscali, finanziamenti e incentivi della Regione Toscana Giovedì 26 novembre 2015 9:45 Polo Tecnologico e startup innovative Nico Cerri 10:00 Dall

Dettagli

Introduzione a PowerSchedO

Introduzione a PowerSchedO Il sistema di supporto alle tue decisioni Introduzione a PowerSchedO White paper Per maggiori informazioni http://www.powerschedo.it http://www.mbigroup.it PowerSchedO è un marchio registrato MBI. Questo

Dettagli

R. De Pari. CO0142 rev. B 1

R. De Pari. CO0142 rev. B 1 R. De Pari CO0142 rev. B 1 VERIFICA ISPETTIVA PER LA QUALITÀ (O AUDIT DELLA QUALITÀ) - DEFINIZIONE Processo sistematico, indipendente e documentato per ottenere evidenze della Verifica Ispettiva e valutarle

Dettagli