Introduzione all’ALM
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
Deploy
Analisi
requisiti
Testing
Design
Sviluppo
Do your systems talk business? |
2
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? |
3
Waterfall
 Funziona per progetti life-critical
Requisiti
 Le specifiche debbono essere
Design
conosciute nelle fasi iniziali
 Estremamente rigido
Sviluppo
Test
Deploy
Do your systems talk business? |
4
Waterfall per i «salmoni»
 Diminuisce la rigidità
Requisiti
ammettendo la possibilità
di «risalire» la cascata
come un salmone 
Design
Sviluppo
Test
Deploy
Do your systems talk business? |
5
Waterfall Sashimi
 Si sovrappongono le fasi,
Requisiti
una fase successiva inizia
prima del completamento
della precedente
Design
Sviluppo
Test
Deploy
Do your systems talk business? |
6
Verso processi evolutivi - Spiral
Do your systems talk business? |
7
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? |
8
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? |
9
Staged Delivery
 Al fine di gestire specifiche
in continuo cambiamento
alcuni passi vengono
scomposti
Requisiti
Design
architetturale
Design
Code
Test
delivery
Design
Code
Test
delivery
Design
Code
Test
delivery
Do your systems talk business? |
10
Evolutionary delivery
Requisiti
Design
architetturale
Sviluppo
Incorporate
Feedback
Deploy
Final Version
Customer
Feedback
Do your systems talk business? |
11
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? |
12
Agile Manifesto
 Our highest priority is to satisfy the customer
through early and continuous delivery
of 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? |
13
Frizione nella comunicazione
 I problemi maggiori nascono dal far comunicare
tra loro figure tecniche e non tecniche
Realizzeremo tutto in WPF
con supporto servizi WCF
in ottica SOA …a
??????????????a
Do your systems talk business? |
14
Non chiarezza dei requisiti
 Una raccolta errata dei requisiti è la causa primaria
di problemi nel progetto
Vorrei un piccolo gestionale
per il mio magazzinoa
Nessun problemaa
Do your systems talk business? |
15
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 integrale
perché nella mia azienda…
Do your systems talk business? |
16
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? |
17
Elicitazione requisiti
 Tramite prototipi di interfaccia, use case ed altre
tecniche, il cliente viene introdotto maggiormente
nelle fasi di progetto
L’utente web deve poter inserire un ordine
ccccccccccc
Non vedo l’icona di PayPal
Do your systems talk business? |
18
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? |
19
Scrum
Do your systems talk business? |
20
Feedback frequenti
 Con processi come Scrum, ogni due settimane è
possibile far vedere allo stakeholder il «deliverable»
Questo è un primo prototipo
Mi piace, ma vorrei che fosse Blu
Do your systems talk business? |
21
Feedback Frequenti
Questa è la versione attuale
Abbiamo aggiunto XYZ
Ha la trazione integrale ed i vetri oscurati?
Do your systems talk business? |
22
Feedback frequenti
Ecco la versione attuale
Abbiamo introdotto z, w e k
Io cambierei qualcosina, vorrei che….
Do your systems talk business? |
23
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.
Do your systems talk business? |
24