Introduzione all'ALM

  • 359 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
359
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
12
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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