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

[email protected]

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


Definizione dei requisiti Analisi Disegno Realizzazione Collaudo e test

Prototipi

• Prototipo e mappa di navigazione

• Presentazione al cliente




Piano di lavoro

• Diagrammi di Gantt




Specifiche funzionali

• Comportamento atteso del sistema

Specifiche non funzionali

• Proprietà che il sistema deve rispettare:

• Prestazioni

• Compatibilità

• Usabilità

• Affidabilità

• Sicurezza

• Manutenibilità

• Portabilità


15


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


16


Prototipo

• Oggetti

• Sezioni

• Navigazioni


17


Piano dei test

• Approccio e organizzazione dei test del sistema

• Tipologia di test che HP vuole effettuare e obiettivi


18




19

Prototipo

Familiarità per l’utente

Consistenza

Minime sorprese

Ripristinabilità

Diversità degli utenti

Guida dell’utentePrototipo

• Principi della progettazione di interfacce utente



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



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



22

Misurazione della qualità del codice sorgente

• CAST

Indicatori usati:

• Transferability

• Changeability

• Robustness

• Performance

• Security



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



24

Documentazione utente

• Manuale utente

• Guida online contestuale



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)


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


27


La fase di collaudo e test si è conclusa il 23 dicembre 2014

con l’accettazione del software da parte di Rai


28


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


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


Manage requirements

• Documentare esplicitamente.

• RUP descrive come raccogliere, organizzare e documentare i requisiti del sistema.

• RUP descrive come tracciare accordi e decisioni prese.

39


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


Visually model software

• Modellare il software visivamente.

• Mostrare struttura e comportamento di architetture e componenti.

• UML

41


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


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


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.


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


• 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


• 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


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

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.scrum.org/

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ITA.pdf

http://www.scrumalliance.org/

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

http://www.castsoftware.com/products/application-analytics-dashboard

https://balsamiq.com/

https://products.office.com/it-it/project/project-and-portfolio-management-software

http://www.sparxsystems.com/products/ea/

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

gestione di processi in situazioni realiingsoft1/lezioni2008-2009/versionipdf/p… · cambiamento e...

Documents