Gestione di processi in situazioni realiingsoft1/Lezioni2008-2009/versioniPDF/P… · cambiamento e...
Transcript of Gestione di processi in situazioni realiingsoft1/Lezioni2008-2009/versioniPDF/P… · cambiamento e...
Gestione di processiin situazioni realiSilvia Rinaldi
12-13 Dicembre 2016
Agenda
• Presentazione
• Chi sono
• Chi è HPE
• Qual è lo scopo dei due incontri
• Waterfall
• Riepilogo generale
• Come è stato applicato nelle diverse fasi di progetto e con quali strumenti
• Risultati ed evoluzioni del progetto
• Conclusioni
• Q&A
2
• RUP
• Best practice
• Agile Scrum
• riepilogo generale
• come è stato applicato nelle diverse fasi di progetto
• Conclusioni
• Q&A
Presentazione
3
HP Inc.Hewlett Packard Enterprise
Hewlett-Packard
“Today, I’m more convinced than ever that separating HP into two independent, Fortune 50 companies is the right thing to do.”Meg Whitman, Q2 FY2015 results
4
Presentazione
5
HP Inc.Hewlett Packard Enterprise
Hewlett-Packard
Technology Consultant
L’obiettivo di queste due sessioni
• Mostrarvi come viene applicato nella realtà ciò che state studiando nel corso di Ingegneria del Software
• Mostrarvi come NON viene applicato nella realtà ciò che state studiando nel corso di Ingegneria del Software
6
Development Approaches
7
AGILE SCRUMRUPWATERFALL
Predictive Adaptive
Waterfall
8
Waterfall in breve
Fasi separate di lavorazione:
• Definizione dei requisiti
• Progettazione del sistema
• Implementazione e test unitari
• Integrazione e test del sistema
• Operatività e manutenzione
9
Gli output richiesti per ciascuna fase, forniscono l’input per la fase successiva
Senza l’approvazione di tali output, la fase successiva non può cominciare.
Progetto Transition To Tapeless per RAI
10
Processo di digitalizzazione: migrazione di contenuti da supporti fisici
di tipo Tape (pellicole e nastri magnetici), verso supporti di tipo File.
Digitalizzazione per Rai
• Adeguamento e velocizzazione della filiera produttiva
• Conversione dei materiali fisici presenti nei magazzini
Bando di gara Rai per T3 – Transition to Tapeless:acquisizione di prodotti software e servizi specialistici.
Maggio 2011
Assegnazione del progetto a Hewlett Packard Italiana S.r.l.Ottobre
2011
• Progetto T3: modello a cascata
Collaudo e testNovembre 2014 – Dicembre 2014 Accettazione
RealizzazioneAprile 2014 – Novembre 2014 Consegna
DisegnoFebbraio 2014 – Aprile 2014 Approvazione
AnalisiLuglio 2013 – Febbraio 2014 Approvazione
Definizione dei requisitiGennaio 2013 – Luglio 2013 Attivazione
Gestione del progetto
19/12/2016T3 – Transition to Tapeless: progettazione di un software di digitalizzazione 11
Specifiche dei requisiti
• Contesto del progetto
• Obiettivi di business del cliente
• Requisiti della soluzione
Strumenti realizzati
19/12/2016T3 – Transition to Tapeless: progettazione di un software di digitalizzazione 12
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Prototipi
• Prototipo e mappa di navigazione
• Presentazione al cliente
Strumenti realizzati
19/12/2016T3 – Transition to Tapeless: progettazione di un software di digitalizzazione 13
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Piano di lavoro
• Diagrammi di Gantt
Strumenti realizzati
19/12/2016T3 – Transition to Tapeless: progettazione di un software di digitalizzazione 14
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Specifiche funzionali
• Comportamento atteso del sistema
Specifiche non funzionali
• Proprietà che il sistema deve rispettare:
• Prestazioni
• Compatibilità
• Usabilità
• Affidabilità
• Sicurezza
• Manutenibilità
• Portabilità
Strumenti realizzati
15
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Specifiche di progettazione
• Modello logico dei dati
• Lista dei servizi esposti collocati sui vari layer dell’architettura
Modello di analisi
• usecase diagram
• sequence diagram
• attori del sistema e gerarchie
Strumenti realizzati
16
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Prototipo
• Oggetti
• Sezioni
• Navigazioni
Strumenti realizzati
17
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Piano dei test
• Approccio e organizzazione dei test del sistema
• Tipologia di test che HP vuole effettuare e obiettivi
Strumenti realizzati
18
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Strumenti realizzati
19
Prototipo
Familiarità per l’utente
Consistenza
Minime sorprese
Ripristinabilità
Diversità degli utenti
Guida dell’utentePrototipo
• Principi della progettazione di interfacce utente
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Strumenti realizzati
20
GUI
Ob
ject M
od
el
Presentation
Web Service
WSDL
XSD
Documenti XML
XSDXSD
XSD
Ob
ject M
od
el
Disegno di dettaglio
• Interazioni tra i diversi componenti del sistema
• SOAP, WSDL, UDDI
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Strumenti realizzati
21
Codice sorgente
Scrittura del codice:
• Regole generali di buona programmazione
• Regole specifiche, volute dal dipartimento ICT di Rai
Organizzazione del codice:
• Subversion
• RAI.T3.UI.Web / RAI.T3.UI.PWS
Strumenti realizzati
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
22
Misurazione della qualità del codice sorgente
• CAST
Indicatori usati:
• Transferability
• Changeability
• Robustness
• Performance
• Security
Strumenti realizzati
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
23
Piano dei test
• Test unitari di ciascun componente sviluppato
• Casi di test che permettono di collaudare il sistema
Manuale di gestione del software applicativo
• Installazione nuovo ambiente o nuovi server
• Esercizio del sistema
Strumenti realizzati
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
24
Documentazione utente
• Manuale utente
• Guida online contestuale
Strumenti realizzati
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
25
Test del sistema
• Predisposizione dell’ambiente di test in Rai
• Test congiunti: funzionali, di performance e di alta affidabilità
• Operazioni più significative, casi:
– Assenza di carico (es. Login singolo utente, 90 iterazioni)
– Carico atteso a regime ( es. Login 150 utenti, uno al secondo, 30 iterazioni)
– Situazione di picco (es. Login 300 utenti, 2.5 al secondo, 30 iterazioni)
– Situazione di stress
(es. Login 150+t utenti, 3 al secondo, 30 iterazioni, t incrementale)
– Situazione a regime in long running
(es. Login 100 utenti, un utente al secondo, 300 iterazioni)
Strumenti realizzati
26
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e testDefinizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Training
• Ingegneria di Produzione Rai e gruppo di esercizio
• Linee guida sull’interfaccia
• Indicazioni per troubleshooting di primo livello e gestione di base del
sistema
Garanzie di supporto al collaudo
• Figura specializzata per raccogliere segnalazioni di problemi
• Figura tecnica presente in Rai su chiamata entro un giorno lavorativo
• Correzione eventuali anomalie
Strumenti realizzati
27
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e testDefinizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
La fase di collaudo e test si è conclusa il 23 dicembre 2014
con l’accettazione del software da parte di Rai
Strumenti realizzati
28
Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e testDefinizione dei requisiti Analisi Disegno Realizzazione Collaudo e test
Risultati ed evoluzioni
29
Evoluzioni
• Aggiornamento dell’interfaccia grafica
• Manutenzione evolutiva
• Monitoraggio
• Statistiche e KPI (Key Performance Indicator)
• Training
Risultati
• Passaggio in esercizio
• Canale di test
• Gestione del sistema
• Dashboard di monitoraggio
Conclusioni
Difficoltà incontrate e possibili miglioramenti
• Aree tecniche eterogenee
• Contesto nuovo
• Recupero ritardo accumulato nelle prime fasi.
• Reazione degli utenti (resistenza al cambiamento)
• Impatto delle modifiche ai requisiti
• Propagazione degli errori
• Coinvolgimento del cliente
30
31
AGILE SCRUMRUPWATERFALL
Q & A
32
Thank you
33
Gestione di processiin situazioni realiSilvia Rinaldi
12-13 Dicembre 2016
Agenda
• Presentazione
• Chi sono
• Chi è HPE
• Qual è lo scopo dei due incontri
• Waterfall
• Riepilogo generale
• Come è stato applicato nelle diverse fasi di progetto e con quali strumenti
• Risultati ed evoluzioni del progetto
• Conclusioni
• Q&A
35
• RUP
• Best practice
• Agile Scrum
• riepilogo generale
• come è stato applicato nelle diverse fasi di progetto
• Conclusioni
• Q&A
Rational Unified Process
36
Rational Unified Process
Best Practices
• Develop iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Continually verify software quality
• Manage changes
37
Rational Unified Process – Best practices
Develop iteratively
• Consente di sviluppare e consegnare funzionalità basandosi su priorità del cliente.
• Permette la comprensione dello scenario e dei requisiti in maniera incrementale, attraverso raffinamenti successivi.
• Consente di incrementare il prodotto attraverso iterazioni multiple.
• Permette di mitigare i rischi di un requisito non bene interpretato attraverso i molteplici deploy, con il coinvolgimento del cliente/utenti finali e i loro feedback.
• Il team di sviluppo è maggiormente focalizzato nella produzione del risultato, dato che ogni iterazione termina con una release.
38
Rational Unified Process – Best practices
Manage requirements
• Documentare esplicitamente.
• RUP descrive come raccogliere, organizzare e documentare i requisiti del sistema.
• RUP descrive come tracciare accordi e decisioni prese.
39
Rational Unified Process – Best practices
Use component-based architectures
• RUP fornisce le linee guida per la progettazione di architetture flessibili, in grado di accogliere cambiamenti
• Componenti riutilizzabili.
• RUP incoraggia architetture che usano componenti nuovi e componenti esistenti.
40
Rational Unified Process – Best practices
Visually model software
• Modellare il software visivamente.
• Mostrare struttura e comportamento di architetture e componenti.
• UML
41
Rational Unified Process – Best practices
Continually verify software quality
• La qualità di un software deve essere considerata come un requisito.
• RUP prevede la pianificazione, la progettazione, l’esecuzione e la valutazione di test di qualità.
• I test di qualità appartengono al processo, non sono quindi considerati come una attività separata da assegnare ad un altro gruppo.
42
Rational Unified Process – Best practices
Manage changes
• Il processo descrive come verificare, tracciare e monitorare ciascun cambiamento del software per evitare impatti sullo sviluppo in corso.
• RUP fornisce linee guida su come gestire più workspace. Ciascun workspace ha lo scopo di isolare i file su cui sta lavorando uno sviluppatore, dai cambiamenti che impattano altri workspace.
• E’ necessario un software per il versionamento di tutti gli artifacts di un progetto (codice, documenti, modelli).
43
Enterprise Architect – Sparx Systems
44
Agile Unified Process
« L'Agile Unified Process (AUP) è una versione semplificata, sviluppata da Scott Ambler, dell'IBM RationalUnified Process (RUP). Essa descrive un approccio allo sviluppo di applicazioni software, semplice, facileda comprendere e che utilizza tecniche e concetti agili pur rimanendo fedele al processo RUP.
Scott Ambler ha cercato di mantenere Agile UP il più semplice possibile, sia nell'approccio che nella suadescrizione.
L'AUP applica le tecniche di sviluppo agile tra cui test driven (TDD), Agile Modeling, gestione agile delcambiamento e refactoring del database per migliorare la produttività. »
https://it.wikipedia.org/wiki/Agile_Unified_Process
45
46
AGILE SCRUMRUPWATERFALL
Agile Scrum
47
Agile
http://www.wordreference.com/definition/agile
adj.
• quick and well-coordinated in movement;
• marked by an ability to think quickly; mentally acute or aware
48
http://en.oxforddictionaries.com/definition/agile
adj.
• able to move quickly and easily;
• able to think and understand quickly;
• relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. Contrasted with ‘Waterfall’.
Agile Manifesto
49
Agile Manifesto
50
Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
http://agilemanifesto.org/
Principi del Manifesto Agile (1/2)
1. La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
2. Accogliamo i cambiamenti nei requisiti, anche in stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
3. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
5. Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.
51
Principi del Manifesto Agile (2/2)
52
7. Il software funzionante è il principale metro di misura di progresso.
8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante.
9. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità.
10. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.
11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
Approccio Agile
53
Features
FeaturesTime Cost
Time Cost
Traditional Approach Agile Approach
Fixed
Variable
QualityQuality
Features/Functions used in a typical system
Never45%
Rarely19%
Sometimes16%
Often13%
Always7%
54
Standish Group Study reported at XP2002 by Jim Johnson, Chairman
Never / Rarely Used
64%
Often / Always Used
20%
Agile Scrum
55
Definizione
Un framework che consente alle persone di risolvere problemi complessi di tipo adattivo e, al tempo stesso, di creare e rilasciare prodotti in modo efficace e creativo dal più alto valore possibile.
Scrum è:
• Leggero
• Semplice da comprendere
• Molto difficile da padroneggiare
Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche.
The Scrum Guide - Ken Schwaber, Jeff Sutherland
Agile Scrum
56
Teoria
Scrum si basa sulla teoria del controllo empirico dei processi, o empirismo.
L’empirismo afferma che la conoscenza deriva dall’esperienza e che le decisioni si basano su ciò che si conosce.
Scrum utilizza un metodo iterativo ed un approccio incrementale per ottimizzare la prevedibilità ed il controllo del rischio.
I pilastri che sostengono ogni implementazione del controllo empirico di processo sono:
• Trasparenza
• Ispezione
• Adattamento
The Scrum Guide - Ken Schwaber, Jeff Sutherland
Agile Scrum
57
Trasparenza
La trasparenza richiede che gli aspetti significativi del processo siano definiti da uno standard comune inmodo tale che gli osservatori condividano una comune comprensione di ciò̀ che viene visto.
Ispezione
Chi utilizza Scrum deve ispezionare frequentemente gli artefatti di Scrum e l’avanzamento verso un obiettivocon lo scopo di rilevare le eventuali deviazioni indesiderate.
Adattamento
Se chi ispeziona verifica che uno o più aspetti del processo sono al di fuori dei limiti accettabili e che ilprodotto finale non potrà essere accettato, deve adattare il processo o il materiale ad esso relativo.
L’adattamento deve essere portato a termine il più rapidamente possibile per ridurre al minimo l’ulterioredeviazione.
The Scrum Guide - Ken Schwaber, Jeff Sutherland
Scrum Roles
Il modello di team in Scrum è progettato per ottimizzare la
flessibilità, la creatività e la produttività.
• Auto-organizzato
• Cross-funzionale
58
Scrum Framework
59
Aspetti fondamentali
• Time-boxing
Tutti gli eventi sono a finestra temporale prefissata (timeboxed), così da avere una durata massima predefinita.
• Definition of Done (DoD)
Definizione di “Fatto”. I membri dello stesso Team di Scrum devono avere una comprensione condivisa di ciò che si intenda per lavoro completo, al fine di assicurare che ci sia trasparenza.
• Responsabilità del Development Team
Il Team di Sviluppo è responsabile di tutte le stime. Coloro che effettuano le stime sono gli stessi che eseguiranno il lavoro.
• Estimation
La stima deve essere fatta in Team. Tecniche di stima: Planning Poker, Triangolazione, Affinità.
60
Aspetti fondamentali
• Backlog Item – User Story
As a ... , I want to ... [so that ...]
A story must be INVEST, to allow PO to order it within the business value.
• Independent
• Negotiable
• Valuable to customer
• Estimatable (Story Point)
• Small
• Testable
Es.
«Come amministratore del sistema devo poter gestire gli utenti registrati»
«Come amministratore del sistema devo poter fare il reset password di un utente registrato»
61
Aspetti fondamentali
• Velocity
Velocità del Development Team. Quanti Story Point il team riesce a completare in ogni Sprint. All’inizio si tratta di una previsione, col passare delle iterazioni la misura diventa più precisa.
• Burndown chart
Grafico che mostra la quantità di lavoro che manca per raggiungere l’obiettivo. Evidenzia eventuali ritardi o anticipi rispetto alle previsioni. Può essere aggiornato velocemente se vengono aggiunti/rimossi PBI.
62
Burn-down chart
63
0
10
20
30
40
50
60
70
80
90
100
Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6 Sprint7 Sprint8 Sprint9 Sprint10
Burn-down chart con nuovi Item nel Product Backlog
64
0
10
20
30
40
50
60
70
80
90
100
Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6 Sprint7 Sprint8 Sprint9 Sprint10
65
AGILE SCRUMRUPWATERFALL
Riepilogo
66
Waterfall
• Recupero ritardo accumulato nelle prime fasi.
• Impatto delle modifiche ai requisiti nelle
successive fasi.
• Propagazione degli errori.
Agile Scrum
• Sono pochi i clienti in grado di apprezzare questo
framework.
• Difficoltà contrattuali tra cliente e fornitore.
• Estrema fiducia tra cliente e fornitore.
• Estrema fiducia all’interno dello Scrum Team.
Waterfall VS Agile
67
«The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.»
Waterfall VS Agile
• “The CHAOS Manifesto” è relativo a progetti analizzati dal 2002 al 2010.
• “The CHAOS Manifesto” è relativo a progetti realizzati per enti pubblici e privati.
• “The CHAOS Manifesto” non fornisce indicazioni sul numero di progetti analizzati.
• “The CHAOS Manifesto” non fornisce indicazioni sulle dimensioni dei progetti analizzati.
68
Q & A
69
Bibliografia
– Sommerville I., Ingegneria del software, 8 ed., Pearson Addison Wesley
– R. Dennis Gibbs, Project Management with the IBM Rational Unified Process Lessons from the Trenches
– Rational Unified Process Best Practices for Software Development Teams - Rational Software White Paper TP026B, Rev 11/01 https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
– http://www.ambysoft.com/unifiedprocess/agileUP.html
– https://it.wikipedia.org/wiki
– http://agilemanifesto.org
– http://www.wordreference.com/definition/agile
– http://en.oxforddictionaries.com/definition/agile
– http://www.scrum.org
– http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ITA.pdf
– http://www.scrumalliance.org
70
Link utili
– CAST: http://www.castsoftware.com/products/application-analytics-dashboard
– Balsamiq: https://balsamiq.com
– MS Project: https://products.office.com/it-it/project/project-and-portfolio-management-software
– Enterprise Architect: http://www.sparxsystems.com/products/ea/
71
Thank you
72
Principio di Pareto (o legge 80/20)
Nel 1897 l’economista Vilfredo Pareto (1848-1923), studiando la distribuzione dei redditi, dimostrò che inuna data regione solo pochi individui (circa il 20% della popolazione) possedevano gran parte dellaricchezza (circa l’80%).
73
Applicazione nell’informatica:
• l'80% degli errori è contenuto nel 20% del codice
• l'80% delle operazioni degli utenti sono svolte usando il 20% delle funzioni a
disposizione