introduzione all'alm
DESCRIPTION
Slide relative all'intervento durante il 16° workshop dotnetmarche. Breve introduzione all'Application Lifecycle ManagementTRANSCRIPT
Introduzione all’ALM
Do your systems talk business? | 3
Perché ALM Un progetto non è solo «codice», ma un
insieme di attività che va dall’analisi dei requisiti fino al deployment per finire con la manutenzione
Analisi requisi
ti
Design
Sviluppo
Testing
Deploy
Do your systems talk business? | 4
Code and fix
Rappresenta la «non gestione» dell’ALM Funziona per team piccoli e per piccoli
progetti Produce codice di bassa qualità, non
manutenibile
Do your systems talk business? | 5
WaterfallRequisi
ti
Design
Sviluppo
Test
Deploy
Funziona per progetti life-critical
Le specifiche debbono essere conosciute nelle fasi iniziali
Estremamente rigido
Do your systems talk business? | 6
Waterfall per i «salmoni»Requisi
ti
Design
Sviluppo
Test
Deploy
Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone
Do your systems talk business? | 7
Waterfall SashimiRequisi
ti
Design
Sviluppo
Test
Deploy
Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente
Do your systems talk business? | 8
Verso processi evolutivi - Spiral
Do your systems talk business? | 9
La crisi dei modelli classici I modelli classici sono troppo rigidi Il software si è evoluto, non è solo
appannaggio dei militari o delle grandi aziende
Le dimensioni dei progetti sono molto variabili
Specifiche non immutabili
Do your systems talk business? | 10
I believe the hard part of building software to be the specification, design, and testing of conceptual constructr, not the labor of representing it and testing the fidelity of the representation.
The hardest single part of building a software system is deciding precisely what to build
The mythical man month.
Do your systems talk business? | 11
Staged Delivery
Requisiti
Design architettura
le
Design Code Test delivery
Design Code Test delivery
Design Code Test delivery
Al fine di gestire specifiche in continuo cambiamento alcuni passi vengono scomposti
Do your systems talk business? | 12
Evolutionary delivery
Requisiti
Design architettura
le
Sviluppo
Deploy
Customer Feedback
Incorporate
Feedback
Final Version
Do your systems talk business? | 13
Ecosistema Con l’evolutionary delivery viene introdotto
un fattore importante, il cliente o Stakeholder
Gli obiettivi si spostano sempre più verso la «soddisfazione del cliente»
Nasce l’agile manifesto
Do your systems talk business? | 14
Agile Manifesto Our highest priority is to satisfy the
customerthrough early and continuous deliveryof valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Do your systems talk business? | 15
Frizione nella comunicazione I problemi maggiori nascono dal far
comunicare tra loro figure tecniche e non tecniche
Realizzeremo tutto in WPFcon supporto servizi WCFin ottica SOA …a
??????????????a
Do your systems talk business? | 16
Non chiarezza dei requisiti
Una raccolta errata dei requisiti è la causa primaria di problemi nel progetto
Nessun problemaa
Vorrei un piccolo gestionaleper il mio magazzinoa
Do your systems talk business? | 17
Mancato feedback del cliente Il software viene fatto vedere al cliente solo
nelle fasi terminali, quando effettuare cambiamenti è comunque più oneroso in termini di tempo
Il software è pronto
Vorrei inserire la trazione integraleperché nella mia azienda…
Do your systems talk business? | 18
Processi agili
I processi agili, come SCRUM o Extreme Programming inseriscono lo Stakeholder direttamente nel processo
Tramite piccole release incrementali lo Stakeholder è in grado di dare feedback costanti ed «aggiustare» la direzione
L’uso di strumenti come Casi d’uso e prototipi di interfaccia permette alle varie figure di gestire le specifiche senza linguaggio tecnico
Do your systems talk business? | 19
Elicitazione requisiti Tramite prototipi di interfaccia, use case ed
altre tecniche, il cliente viene introdotto maggiormente nelle fasi di progetto
ccccccccccc
L’utente web deve poter inserire un ordine
Non vedo l’icona di PayPal
Do your systems talk business? | 20
The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability
The mythical man month.
Do your systems talk business? | 21
Scrum
Do your systems talk business? | 22
Feedback frequenti
Questo è un primo prototipo
Con processi come Scrum, ogni due settimane è possibile far vedere allo stakeholder il «deliverable»
Mi piace, ma vorrei che fosse Blu
Do your systems talk business? | 23
Feedback Frequenti
Questa è la versione attualeAbbiamo aggiunto XYZ
Ha la trazione integrale ed i vetri oscurati?
Do your systems talk business? | 24
Feedback frequenti
Ecco la versione attualeAbbiamo introdotto z, w e k
Io cambierei qualcosina, vorrei che….
Do your systems talk business? | 25
Come procederemo
Nel corso della giornata verranno trattati con dettaglio gli argomenti qui esposti
Si partirà con un intervista al cliente, per passare poi ad un prototipo di applicativo
Sviluppatori e Designer lavoreranno al progetto curando ogniuno la sua parte
Infine il software verrà messo in integrazione continua affinche il cliente possa verificare il software durante il corso dello sviluppo.