Slide relative all'intervento durante il 16° workshop dotnetmarche. Breve introduzione all'Application Lifecycle Management

1. Introduzione all’ALM

2. Chi sono Ricci Gian Maria Alkampfer@nablasoft.com http://www.codewrecks.com http://blogs.ugidotnet.org/rgm

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

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

5. Waterfall Funziona per progetti life-critical Le specifiche debbono essere conosciute nelle fasi iniziali Estremamente rigido

6. Waterfall per i «salmoni» Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone 

7. Waterfall Sashimi Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente

8. Verso processi evolutivi - Spiral

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

10. I believe the hard part of building software to be the specification, design, and testing of conceptualconstructr, not the labor of representingit and testing the fidelity of the representation. The hardest single part of building a software systemisdecidingpreciselywhat to build The mythical man month.

11. Staged Delivery Al fine di gestire specifiche in continuo cambiamento alcuni passi vengono scomposti

12. Evolutionary delivery Final Version

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

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.

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

16. Non chiarezza dei requisiti Una raccolta errata dei requisiti è la causa primaria di problemi nel progetto Vorrei un piccolo gestionaleper il mio magazzinoa Nessun problemaa

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…

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

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

20. The purpose of the prototypeis to makereal the conceptualstructurespecified, so that the client can test it for consistency and usability The mythical man month.

21. Scrum

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

23. Feedback Frequenti Questa è la versione attuale Abbiamo aggiunto XYZ Ha la trazione integrale ed i vetri oscurati?

24. Feedback frequenti Ecco la versione attuale Abbiamo introdotto z, w e k Iocambierei qualcosina, vorrei che….

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.