Introduzione all'ALM

592 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
592
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Introduzione all'ALM

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

×