• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduzione all'ALM
 

Introduzione all'ALM

on

  • 546 views

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

Statistics

Views

Total Views
546
Views on SlideShare
546
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduzione all'ALM Introduzione all'ALM Presentation Transcript

    • Introduzione all’ALM
    • Chi sono
      Ricci Gian Maria
      Alkampfer@nablasoft.com
      http://www.codewrecks.com
      http://blogs.ugidotnet.org/rgm
    • 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
    • Code and fix
      Rappresenta la «non gestione» dell’ALM
      Funziona per team piccoli e per piccoli progetti
      Produce codice di bassa qualità, non manutenibile
    • Waterfall
      Funziona per progetti life-critical
      Le specifiche debbono essere conosciute nelle fasi iniziali
      Estremamente rigido
    • Waterfall per i «salmoni»
      Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone 
    • Waterfall Sashimi
      Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente
    • Verso processi evolutivi - Spiral
    • 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
    • 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.
    • Staged Delivery
      Al fine di gestire specifiche in continuo cambiamento alcuni passi vengono scomposti
    • Evolutionary delivery
      Final Version
    • 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
    • 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.
    • 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
    • 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
    • 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…
    • 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
    • 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
    • The purpose of the prototypeis to makereal the conceptualstructurespecified, so that the client can test it for consistency and usability
      The mythical man month.
    • Scrum
    • 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
    • Feedback Frequenti
      Questa è la versione attuale
      Abbiamo aggiunto XYZ
      Ha la trazione integrale ed i vetri oscurati?
    • Feedback frequenti
      Ecco la versione attuale
      Abbiamo introdotto z, w e k
      Iocambierei qualcosina, vorrei che….
    • 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.