Introduzione ad ALM

ALM sta per Application Lifecycle Management e rappresenta un insieme di modus-operandi atti a gestire la delicata fase di sviluppo di un software complesso.

Perchè ALM?

Durante lo sviluppo di un progetto, quasi sempre si sottovaluta la gestione del ciclo di vita di un software e spesso si arriva ad un punto molto simile a questo:
shanghai
Praticamente il software arriva in fondo, funzionicchia ma sarebbe migliorabile se non fosse per il fatto che toccando un BIT da una parte smettono di funzionare altre 10 cose dall’altra (il cosidetto maintenance nightmare).
Spesso infatti il developer è così focalizzato sullo sviluppo di una funzionalità e sullo scrivere codice che perde la visione d’insieme del progetto.
In realtà ho deciso di fare questo post perchè, ci si è accorti (fonti attendibili tranquilli) che il fallimento o il successo di un progetto complesso è dato nella maggior parte dei casi, dalla mancanza di gestione del ciclo di vita di un software piuttosto che dalla scelta dell’ambiente di sviluppo o dalle capacità di un team o degli analisti.
Lo so che sembra incredibile, io stesso stentavo a crederlo e mi sono ricreduto dopo essermi informato.
Da qui la risposta al titolo, “perchè ALM?”, perchè un progetto complesso sviluppato senza modus-operandi è un progetto destinato a soffrire moltissimo con il passare del tempo.

Le fasi previste in un progetto:
Analisi dei requisiti
Per requisiti non bisogna intendere solo le funzionalità che dovranno essere presenti nel sistema ma una descrizione in linguaggio semplice ma molto dettagliato di tutte le richieste del committente (estetica, accessibilità, performance, sicurezza, ecc.) e più in generale qualsiasi cosa che possa influire sul software da realizzare.
Design
Nella fase di analisi del design si decidono ambienti di sviluppo, tecnologie, architettura su cui creare il software, sembra una banalità, ma questa fase è critica, al giorno d’oggi con le infinite possibilità offerte, fare una oculata scelta lungimirante non è affatto banale, è una scommessa.
Sviluppo
Attività ormai nota in certi ambienti 🙂
Testing
La fase di testing, seppur possa essere svolta manualmente, è consigliabile “automatizzarla” con adeguati strumenti, i test per quanto sembrano inutili, sono l’unico modo che abbiamo per determinare l’impatto di una modifica sull’intero software in modo veloce e preciso.
Deploy
Procedura (il più possibile automatizzata) che dalla compilazione mi crea il prototipo funzionante da mostrare al cliente in un ambiente di test.
L’ordine con cui le fasi vengono svolte le fasi

Ordinerò l’evoluzione delle metodologie cronologicamente partendo dal metodo più vecchio per arrivare ad oggi, omettendo le date perchè non sono il mio forte.

Code and Fix

codefix
Descrivo scherzosamente la metodologia code and fix: prendete 10 programmatori, chiudeteli in una stanza per 40 ore e questi produrranno alla fine qualcosa.
Purtroppo questa metodologia di sviluppo è valida solo se sto facendo programmi semplici e che difficilmente vedranno la versione 1.2, se adottata in progetti più grandi comporta non pochi problemi.
Ecco lo scenario più ricorrente in un progetto complesso: dico al team voglio un software per gestire QUI QUO QUA e alla fine del processo ci si ritrova un software che gestisce QUI, PIPPO PLUTO e QUA.
Il risultato è che c’è da lavorare doppiamente per adeguare il software alle richieste del cliente scrivendo nuovo codice e fixando il vecchio.

Waterfall

waterfall
Questa metodologia di sviluppo prevede l’esecuzione dei vari processi di sviluppo in cascata, si parte dall’analisi dei requisiti e si arriva dopo alcuni step alla distribuzione all’utente finale.
Questa metodologia è consigliata solo per progetti life-critical, ovvero progetti dove i requisiti del software da creare sono stampati sulla pietra, immutabili, pena la vita di qualcuno ad esempio. In parole povere per progetti life-critical intendo progetti dove un bug può far cadere un aereo oppure scontrare un treno.

Waterfall tuttavia si è dimostrato spesso troppo rigido per lo sviluppo di software ampi, dove prevedere tutti i requisiti è spesso un’operazione impossibile, di conseguenza, sono nate due varianti: waterfall per i salmoni e waterfall sashimi.

Waterfall per i salmoni

Identico al waterfall classico ma con la possibilità di tornare allo step precedente, per esempio, se nella fase di design mi accorgo che un requisito è stato dimenticato, come un salmone, risalgo la cascata e rieseguo l’analisi dei requisiti.
Se mi accorgessi in fase di testing della mancanza di un requisito dovrei risalire la cascata rianalizzando il codice, il design ed i requisiti (cosa molto onerosa in termini di tempo se fatta una per volta).

Watefall sashimi

Mi aggancio all’ultima frase qui sopra dove parlo dell’onerosità temporale nello sviluppo step per step a compartimenti stagni per descrivere il waterfall sashimi.
Il waterfall sashimi prevede la stesura dei requisiti e contestualmente l’inizio della fase di design, cioè, mentre sto terminando la fase dove decido i requisiti, inizio a decidere la fase di design, sovrapponendo il lavoro come il pesce viene “mescolato” nel sashimi.
Stessa cosa, mentre sto per finire la fase di design inizio a scrivere il codice e così via, tutto ciò, per risparmiare tempo ed accorciare i tempi di creazione e manutenzione del software senza intaccarne la qualità.

Spiral

Spiral
Il modello spiral è la prima grande rivoluzione nella metodologia di sviluppo di un software, il progetto di un software complesso deve infatti poter prevedere la flessibilità dei requisiti che variano con il passare del tempo, nel processo spiral, i vari step vengono affrontati più volte in un ciclo virtualmente infinito.
Ogni volta ci sarà una cosa nuova da implementare verranno riesaminati i requisiti, rivalutato il design, scritto nuovo codice, rivisto il vecchio codice ecc… in un processo che aumenta esponenzialmente la sua complessità.
Questo modello è valido se si hanno a disposizione molte persone su un solo progetto, nasce nell’1988 (vado a memoria) e a quei tempi, un super computer aveva costi superiori al milione di euro, non rappresentava un problema avere un team altrettanto vasto e costoso per star dietro ad uno sviluppo così oneroso.
Al giorno d’oggi per un computer 1000 volte più potente bastano 400 euro, è impensabile investire milioni di euro per creare qualcosa fatto ad-hoc per un pc da 400 euro, quindi è un sistema superato e sostituito da metodi più efficienti.

Processi classici VS processi agili

Fin qui abbiamo analizzato tutti i processi di sviluppo classici, l’evoluzione però delle metodologie di sviluppo ha portato ad un nuovo assunto importante: i requisiti sono spesso in costante mutamento ed inoltre ci sono requisiti più importanti a cui dare una priorità maggiore e requisiti che è possibile implementare nella fase finale del progetto, si inizia cioè a pianificare quali dei requisiti implementare per prima, da qui (ma non solo) nasce il manifesto agile.

Manifesto Agile (si pronuncia agiail)

Il manifesto agile nasce nel 2001 da un’attenta analisi sul modo di lavorare di molte software house con l’intenzione di abbattere i costi dello sviluppo di un software e soprattutto con l’obbiettivo più importante, che non è creare un software ma soddisfare chi ce lo commissiona.
Tutti i metodi agili prevedono infatti una figura fondamentale nel progetto, lo stakeholder, cioè colui che abbia interesse che ciò che sia fatto non sia sbagliato, quindi solitamente, lo stakeholder è il cliente, di certo non sarà mai lo sviluppatore o l’analista.
I metodi cosiddetti “agili”, vivono e si basano sul feedback dello stakeholder, prevedono per questo, che dopo ogni modifica si arrivi ad un prototipo funzionante da mettere nelle mani del cliente con una cadenza che va dalle 2 settimane a 2 mesi.
Quindi in sostanza, si sviluppa, si compila, si mette il cliente in condizione di testare quello che si è creato per avere un feedback fin dallo stato embrionale del progetto.
Tutto questo ci evita di arrivare alla scadenza con un software che tradisce le aspettative del cliente.
E’ stato dimostrato infatti che è molto meglio arrivare alla scadenza anche con metà del programma fatto come vuole il cliente e funzionante piuttosto che arrivare a scadenza con un programma che è all’incontrario di come il cliente se lo aspettava.
Quando parlo di questi aspetti considero anche le conseguenze come gli insoluti, che spesso arrivano proprio dall’insoddisfazione del cliente che ha ordinato una Ferrari rossa e si ritrova una cosa che gli assomiglia vagamente di colore bordeaux.
Nel tempo sono stati testati molti modelli di sviluppo agili (staged delivery, evolutionary delivery ecc…) e attualmente quello più utilizzato nel mondo è SCRUM.

SCRUM (si pronuncia scram)

Scrum
Scrum rappresenta l’attuale metodo con cui la maggior parte dei software mediamente complessi vengono concepiti, realizzati e manutenuti. E’ in poche parole la risposta che ci permette di sfruttare al meglio le risorse di un team e renderle costantemente produttive nel tempo sullo stesso progetto.
Tutto parte e viene deciso in base alle esigenze dello stakeholder che ci dirà i requisiti da implementare nel software e la loro relativa priorità all’interno del processo di sviluppo.
Quindi il progetto parte da un insieme ben preciso di requisiti che a scadenza dovremo aver implementato (il cosiddetto product backlog).
Ora il ruolo della software house è di analizzare questi requisiti e fornire un prototipo di interfaccia su carta delle schermate e dei passaggi che andremo a realizzare per avere un confronto produttivo con il cliente.
NB: è sempre molto importante evitare di parlare con il cliente con un linguaggio tecnico che, seppure possa dare l’impressione di essere competenti, sicuramente tenderà ad aumentare la possibilità di fraintendimenti.
Successivamente un analista (con conoscenze tecniche) scomporrà in ore uomo la realizzazione dei vari requisiti (sprint backlog).
Il lavoro di sviluppo verrà organizzato in sprint da 2 settimane ad un massimo di 2 mesi privilegiando sprint corti, e, in base alla priorità che il cliente ci ha dato per i vari requisiti, decideremo quelli da cui partire nel primo sprint e via via proseguiremo a sviluppare il resto con i sprint successivi.
Ora, considerando un team di X persone, considerando pause sigarette, pause facebook, tempo per leggere le mail ecc… con un po’ di tempo e pratica riusciamo a determinare con precisione estrema le varie scadenze.
Lo sviluppo di uno sprint inoltre verrà scomposto in workitem risolti e da risolvere, sapendo che idealmente possiamo risolvere diciamo 5 workitem al giorno, possiamo tracciare un grafico con la linea ideale da seguire e vedere se siamo in ritardo o in anticipo con i lavori rispetto allo zero (dove lo sprint è completato).
workitem
Una volta ultimati i primi sprint, già ci si rende conto se si è stati ottimisti o pessimisti nella valutazione delle ore uomo pianificate e da li si possono ottimizzare ulteriormente le tempistiche e le scadenze.
Al termine di ogni sprint, sarà compito della software house fornire un prototipo anche semi-funzionante al cliente che potrà darci un feedback costruttivo.
NB: con feedback costruttivo intendo che nel team bisogna assumersi la responsabilità, quando una cosa non va bene, di buttarla e rifarla da zero e non di doverla far andar bene per forza aggiustandola 🙂
Non lo dico io, ma il manifesto agile, il team deve essere in grado anche di assorbire il drop di una parte sviluppata erroneamente.

Bene, ho terminato, sta volta spero di non esser stato noioso ed aver dato nuovi spunti interessanti, la pagina su wikipedia di SCRUM è ben fatta, se volete approfondire la consiglio.

Rispondi

Leggi articolo precedente:
Enterprise Service Bus questo sconosciuto?!

Un Enterprise Service Bus (ESB) è un'infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse.

Chiudi