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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

Dettagli

Il 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

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

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

Il Controllo di gestione nella piccola impresa

Il Controllo di gestione nella piccola impresa Stampa Il Controllo di gestione nella piccola impresa admin in A cura di http://www.soluzionipercrescere.com La piccola impresa presenta generalmente un organizzazione molto snella dove l imprenditore

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LE COMPETENZE DI FUNDRAISING (CF) INSEGNATE AL MASTER

LE COMPETENZE DI FUNDRAISING (CF) INSEGNATE AL MASTER LE COMPETENZE DI FUNDRAISING (CF) INSEGNATE AL MASTER Indice INTRODUZIONE... 3 CF1 - SVILUPPARE IL CASO PER IL FUNDRAISING... 4 CF 1.1 : INDIVIDUARE LE NECESSITÀ DI FUNDRAISING DI UN ORGANIZZAZIONE NONPROFIT;...

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

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

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

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

www.learningschool.it

www.learningschool.it Piano di Formazione Scuola Vendite Progetto Finanziato dal Fondo Coordinato da e Informazioni: Gli ultimi 2 anni, causati dalla profonda crisi economica internazionale, hanno visto un rallentamento del

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

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

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

GEPRIM Snc. Consulenza, Formazione e Coaching per il Settore Creditizio. www.geprim.it

GEPRIM Snc. Consulenza, Formazione e Coaching per il Settore Creditizio. www.geprim.it GEPRIM Snc Consulenza, Formazione e Coaching per il Settore Creditizio Geprim per il Settore Creditizio Il settore del credito e la figura del mediatore creditizio hanno subito notevoli cambiamenti nel

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

Tecnologie e sistemi per la business integration. www.xdatanet.com

Tecnologie e sistemi per la business integration. www.xdatanet.com Tecnologie e sistemi per la business integration www.xdatanet.com X DataNet, X costruttori DataNet, costruttori di softwaredi software Costruiamo Costruiamo soluzioni tecnologiche soluzioni tecnologiche

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

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

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

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

Come gestire i Social Network

Come gestire i Social Network marketing highlights Come gestire i Social Network A cura di: Dario Valentino I Social Network sono ritenuti strumenti di Marketing imprescindibili per tutte le aziende che svolgono attività sul Web. Questo

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

IDENTITÀ GIOVANE. Nata nel 2006 con l intento di diventare leader nel settore IT, Easytech cresce con una solida competenza in tre divisioni:

IDENTITÀ GIOVANE. Nata nel 2006 con l intento di diventare leader nel settore IT, Easytech cresce con una solida competenza in tre divisioni: copertina pg. 1 immagine pg. 2 Easytech è un gruppo di giovani professionisti uniti da un obiettivo comune: proporre le migliori soluzioni per rendere le imprese leggere e pronte a sostenere la competizione

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

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

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

Guida per i venditori

Guida per i venditori Guida per i venditori Vendere un azienda può essere complicato e impegnativo ed è generalmente un evento che si presenta una volta nella vita. Vi preghiamo di leggere con attenzione i seguenti paragrafi.

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

Marketing mix Prodotto

Marketing mix Prodotto Marketing mix Parlare di marketing mix per il settore pubblico è possibile soltanto prendendo i fattori che lo contraddistinguono ed adattarli al settore. Accanto ai tradizionali quattro fattori: prezzo,

Dettagli

Il materiale ripercorre i presupporti teorici legati al tema del welfare aziendale proponendo quanto emerso in occasione di un intervento in aula.

Il materiale ripercorre i presupporti teorici legati al tema del welfare aziendale proponendo quanto emerso in occasione di un intervento in aula. Il materiale ripercorre i presupporti teorici legati al tema del welfare aziendale proponendo quanto emerso in occasione di un intervento in aula. E possibile approfondire il tema consultando il sito La

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

Cambiare il Sistema Informativo

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

Dettagli

ORGANIZZAZIONE DEL PROGETTO

ORGANIZZAZIONE DEL PROGETTO ORGANIZZAZIONE DEL PROGETTO L organizzazione di un progetto è la realizzazione del processo di pianificazione. In altre parole, organizzare significa far funzionare le cose. Nello specifico, implica una

Dettagli

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ

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

Dettagli

Ridurre i costi logistici attraverso il team working: il caso GD

Ridurre i costi logistici attraverso il team working: il caso GD Ridurre i costi logistici attraverso il team working: il caso GD di Davide Mondaini e Violante Battistella (*) I costi logistici rappresentano una voce rilevante all interno del Conto Economico aziendale.

Dettagli

Il Piano di comunicazione

Il Piano di comunicazione Il Piano di comunicazione 23 lezione 11 novembre 2011 Cosa è un piano di comunicazione Il piano di comunicazione è uno strumento utilizzato da un organizzazione per programmare le proprie azioni di comunicazione

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

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

COME LIMITIAMO NOI STESSI

COME LIMITIAMO NOI STESSI COME LIMITIAMO NOI STESSI 1 Il 63 % delle persone crede che il raggiungimento dei propri obiettivi finanziari sia possibile solo attraverso una grossa vincita Non si può ottenere quello che non si riesce

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

L UOMO L ORGANIZZAZIONE

L UOMO L ORGANIZZAZIONE UNITÀ DIDATTICA 1 L UOMO E L ORGANIZZAZIONE A.A 2007 / 2008 1 PREMESSA Per poter applicare con profitto le norme ISO 9000 è necessario disporre di un bagaglio di conoscenze legate all organizzazione aziendale

Dettagli

Il Marketing Definizione di marketing cinque fasi

Il Marketing Definizione di marketing cinque fasi 1 2 3 Definizione di marketing: il marketing è l arte e la scienza di conquistare, fidelizzare e far crescere clienti che diano profitto. Il processo di marketing può essere sintetizzato in cinque fasi:

Dettagli

TU METTI LE IDEE.. NOI LE SOLUZIONI!!

TU METTI LE IDEE.. NOI LE SOLUZIONI!! TU METTI LE IDEE.. NOI LE SOLUZIONI!! MISSION La mission di CSR Solution è quella di supportare soluzioni software avanzate nei settori della progettazione e della produzione industriale per le aziende

Dettagli

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

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

Dettagli

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

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

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

LA BANCA FORMAZIONE DEL TEAM PER L INNOVAZIONE ED IL CAMBIAMENTO. Programma di sviluppo continuo dell innovazione

LA BANCA FORMAZIONE DEL TEAM PER L INNOVAZIONE ED IL CAMBIAMENTO. Programma di sviluppo continuo dell innovazione LA BANCA FORMAZIONE DEL TEAM PER L INNOVAZIONE ED IL CAMBIAMENTO Programma di sviluppo continuo dell innovazione LA REALTÀ CORRENTE INNOVATION & CHANGE OGGI IL CLIMA GENERALE È CARATTERIZZATO DA CONTINUI

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

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

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

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

Gestione del conflitto o della negoziazione

Gestione del conflitto o della negoziazione 1. Gestione del conflitto o della negoziazione Per ognuna delle 30 coppie di alternative scegli quella che è più vera per te. A volte lascio che siano gli altri a prendersi la responsabilità di risolvere

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

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

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

Caso Pratico Stili di Direzione

Caso Pratico Stili di Direzione In questo caso, vi proponiamo di analizzare anche 4 situazioni relative alla presa di decisioni. Questa documentazione, come sapete già, è centrata su modelli di stili di direzione e leadership, a seconda

Dettagli

"L impatto dell Information Technology sulle aziende del terziario in Italia"

L impatto dell Information Technology sulle aziende del terziario in Italia "L impatto dell Information Technology sulle aziende del terziario in Italia" Sintesi per la stampa Ricerca promossa da Microsoft e Confcommercio realizzata da NetConsulting Roma, 18 Marzo 2003 Aziende

Dettagli

Company Prof.ile. Il chi. Il come. Il perché.

Company Prof.ile. Il chi. Il come. Il perché. Company Prof.ile Il chi. Il come. Il perché. Sommario Introduzione Presentazione Approccio I plus La rete di progetti Servizi Perché scegliere Toast? Clienti Contatti Introduzione Il ruolo delle agenzie

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

SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS.

SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. Efficiente, rapido, su misura. G2 Automotive è l innovativo sistema di gestione specifico

Dettagli

Gestire l impresa per progetti: istruzioni per l uso. Carlo Notari, PMP. Assolombarda - Percorso per l innovazione innovativa. Martedì 24 Ottobre 2006

Gestire l impresa per progetti: istruzioni per l uso. Carlo Notari, PMP. Assolombarda - Percorso per l innovazione innovativa. Martedì 24 Ottobre 2006 Gestire l impresa per progetti: istruzioni per l uso Carlo Notari, PMP Martedì 24 Ottobre 2006 Assolombarda - Percorso per l innovazione innovativa L innovazione E la trasformazione di una nuova idea e

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

Corso di Amministrazione di Sistema Parte I ITIL 1

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

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

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

Il ROI del consolidamento dei Server

Il ROI del consolidamento dei Server Il ROI del consolidamento dei Server Sul lungo periodo, un attività di consolidamento dei server è in grado di far scendere i costi IT in modo significativo. Con meno server, le aziende saranno in grado

Dettagli

La norma ISO 50001 per il risparmio energetico delle aziende

La norma ISO 50001 per il risparmio energetico delle aziende La norma ISO 50001 per il risparmio energetico delle aziende La norma UNI CEI EN ISO 50001:2011 Sistemi di gestione dell energia Requisiti e linee guida per l uso è la versione ufficiale italiana della

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

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

Principi di gestione aziendale per sviluppare l innovazione in azienda. Gestione dell Innovazione a.a. 2004/2005 AB

Principi di gestione aziendale per sviluppare l innovazione in azienda. Gestione dell Innovazione a.a. 2004/2005 AB Principi di gestione aziendale per sviluppare l innovazione in azienda Gestione dell Innovazione a.a. 2004/2005 AB 1 L ECONOMIA DELLA CONOSCENZA Nei prossimi decenni la competizione fra aziende, e sistemi-paese,

Dettagli

Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive

Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive Comitato SGQ Comitato Ambiente Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive Mercoledì, 23 febbraio 2005 - Palazzo FAST (Aula Morandi) Piazzale Morandi, 2 - Milano E' una

Dettagli

Riflessioni sulla e-leadership

Riflessioni sulla e-leadership PIANO NAZIONALE PER LA CULTURA, LA FORMAZIONE E LE COMPETENZE DIGITALI Riflessioni sulla e-leadership (a cura di Franco Patini e Clementina Marinoni) Nella sua più completa espressione l e-leader è una

Dettagli

Evoluzione in atto in ambito MCAD e PLM nelle aziende italiane. Sergio Terzi Università di Bergamo Politecnico di Milano

Evoluzione in atto in ambito MCAD e PLM nelle aziende italiane. Sergio Terzi Università di Bergamo Politecnico di Milano Evoluzione in atto in ambito MCAD e PLM nelle aziende italiane Sergio Terzi Università di Bergamo Politecnico di Milano Evoluzione in atto in ambito Osservatorio GeCo Gestione dei Processi Collaborativi

Dettagli

COME AVERE SUCCESSO SUL WEB?

COME AVERE SUCCESSO SUL WEB? Registro 3 COME AVERE SUCCESSO SUL WEB? Guida pratica per muovere con successo i primi passi nel web MISURAZIONE ED OBIETTIVI INDEX 3 7 13 Strumenti di controllo e analisi Perché faccio un sito web? Definisci

Dettagli

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

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

Dettagli