Evolutive di un software web: dall’analisi dei requisiti al rilascio in produzione

Il processo di realizzazione delle evolutive

I sistemi impattati

In informatica, il processo di realizzazione delle evolutive per il software in essere dell’azienda cliente può coinvolgere sia i sistemi di back end che i sistemi di front end proprietari o di fornitori terzi. Il front end rappresenta, in generale, la parte visibile di un software, quella con cui l’utente può interagire mentre il back end è il componente che consente l’effettivo svolgimento di tali interazioni. I sistemi coinvolti nel progetto sono: Portale web, Middleware e CRM.

Il middleware è un intermediario tra i diversi elementi dell’infrastruttura, è software in grado di mettere in comunicazione i differenti strati architetturali e facilitare il compito di chi ha il ruolo di progettare i singoli componenti (ad esempio una pagina web). L’utilizzo del middleware, può consentire un più elevato livello di servizio per gli utenti, ed un più elevato livello di astrazione per i programmatori, può inoltre facilitare la manutenzione, la stesura e l’integrazione di applicazioni. Il CRM, invece, è una strategia aziendale che pone il cliente al centro del proprio lavoro, accelera il trasferimento di informazioni dal cliente all’organizzazione e viceversa in tutti i settori. Le applicazioni CRM servono a tenersi in contatto con la clientela, a inserire le loro informazioni all’interno del DB e a fornire loro modalità per interagire in modo che tali interazioni possano essere registrate e analizzate.

Le macro-fasi del processo di realizzazione delle evolutive

Il processo di realizzazione delle evolutive è un processo molto complesso e per tanto viene rigidamente strutturato, in cui per ogni fase viene generalmente prodotto un output denominato deliverable. Esistono tre tipi di deliverable: il software prodotto, il servizio erogato e l’eventuale documentazione di supporto. L’evento trigger che avvia l’intero processo è costituito da una RFP (Request for propose), sotto forma di un documento denominato Documento di requisito, redatto dall’azienda cliente, mediante il quale viene richiesta l’implementazione di una nuova funzionalità o la modifica di una esistente. Il documento contiene il dettaglio del requisito che il fornitore dovrà implementare. In generale, i requisiti rappresentano le soluzioni ingegneristiche e tecniche per soddisfare un bisogno dei clienti. In seguito, l’azienda fornitrice provvede ad effettuare una valutazione della fattibilità dei requisiti raccolti. L’analisi è condotta da due punti di vista:

• Tecnico: si indaga la possibilità di sviluppare tecnicamente il requisito;
• Economico/finanziaria: si indaga la convenienza economica della realizzazione del requisito e viene fatta una stima dell’ammontare di capitale necessario.

Durante tale fase è possibile che siano svolti degli incontri tra gli attori in gioco al fine di determinare il livello di comprensione del requisito. Al termine dello studio di fattibilità, viene stilato un documento denominato Schede tecnica, grazie al quale il cliente valuta se la proposta di soluzione copre i desiderata, i costi rientrano nel budget e il piano proposto è in linea con i tempi attesi. Solo dopo queste attività preliminari il progetto viene avviato e si procede con l’ingaggio del team e con la pianificazione di dettaglio delle attività. Nella successiva fase, denominata analisi di dettaglio, sono previsti workshop con il cliente al fine di definire, nella maniera più dettagliata possibile, le nuove funzionalità da implementare per favorire l’avvio degli sviluppi. Per determinare come i requisiti verranno implementati sui sistemi e quale sarà la user experience, vengono redatte le specifiche funzionali nella fase di disegno. Tali specifiche rappresentano l’input della fase successiva, infatti, gli sviluppatori provvedo ad effettuare le dovute implementazioni sui sistemi coinvolti in base a come descritto all’interno delle specifiche funzionali. Terminate le attività di sviluppo, i nuovi requisiti vengono rilasciati in ambiente di test per poter essere testati. Esistono diverse tipologie di test,

nell’ordine: i System Test, test eseguiti in maniera standlone su ciascuna applicazione coinvolta nello sviluppo, gli Integration Test, test eseguiti end-to-end su tutte le componenti applicative coinvolte nel flusso di business, le quali possono essere gestite dal cliente o dal fornitore e User Acceptance test, test eseguiti con gli utenti al fine di verificare con gli stessi il corretto funzionamento delle implementazioni richieste. Durante lo svolgimento delle attività di UAT, qualora il comportamento dei requisiti oggetto di evolutive non sia coerente con quanto atteso dagli utenti, questi hanno la possibilità di richiedere delle CR (change request), le quali dovranno essere valutate, approvate e implementate dal team di sviluppo. Solo dopo aver raccolto l’approvazione da parte degli utenti, si procede con le attività di rilascio, dove i requisiti vengono trasferiti in ambiente di produzione.

Studio di fattibilità

Le attività di tale fase iniziano con la ricezione di una richiesta di un documento di requisito proveniente dall’azienda cliente, in cui sono descritte diverse variabili: descrizione dell’esigenza, analisi as-is, esigenza da risolvere, impatti, vincoli, benefici attesi, linee guida di soluzione. Dopo aver valutato il documento, l’azienda fornitrice provvede ad effettuare lo studio di fattibilità del requisito stilando un documento che contiene la proposta di soluzione e gli impatti sui sistemi. Al fine di redigere in maniera dettagliata il documento di fattibilità e definire correttamente l’effort necessario per l’implementazione del requisito, vengono svolte riunioni periodiche interne tra i membri responsabili dei sistemi impattati. Quando sono previsti impatti su sistemi esterni è necessario coinvolgere anche i fornitori terzi di tali sistemi. L’effort totale sarà dunque dato dalla somma degli sforzi necessari ad implementare il requisito sui vari sistemi, calcolato in giornate/uomo. Al fine di evitare ritardi, la stima, deve tener conto di eventuali problemi di contigency.

Pianificazione

Lo scopo della pianificazione è quello di strutturare le attività di progetto rispettando le tempistiche condivise ed i vincoli presenti, come la disponibilità di risorse, infrastrutture, ecc.

Tale fase include la definizione dello scope, la definizione del bugdet, vincoli e le risorse, la durata delle attività, i ruoli e le responsabili, la conferma del Blueprint della soluzione (possono essere presenti più alternative). Il business Blueprint è un documento in cui viene descritto il processo, la cui stesura viene solitamente fatta dall’azienda fornitrice che, interfacciandosi con il cliente, identifica le esigenze funzionali dettagliate e propone la soluzione da sviluppare. L’approvazione è una milestone di progetto, definendo l’avvio del progetto. In generale, il tempo che solitamente intercorre tra l’attività di pianificazione e quello di rilascio può superare i sei mesi. Durante le attività di pianificazione, il project manager è il principale attore coinvolto in quanto è il responsabile delle relazioni con i clienti. I requisiti per cui è stato valutato positivamente lo studio di fattibilità, vengono accorpati all’interno di un piano detto Piano di release per gestire in maniera efficiente, in termini di costo, tempo e qualità, tutto il processo aziendale (dell’azienda cliente) di change management. Con il termine release, viene indicato il rilascio di una nuova specifica funziona di un software, resa disponibile agli utenti finali. Una release può essere classificata in base alla sua dimensione e si distinguono major release (riguardano evoluzioni sostanziali rispetto alla precedente e inglobano al loro interno più requisiti) e minor release (correzione di bug). Il processo di realizzazione di una major release è un processo molto complesso e per tanto viene rigidamente strutturato. Lo scheduling delle attività del piano di release può essere descritto mediante l’utilizzo di un diagramma di Gaant.

Il piano di progetto prodotto al momento di kick-off è generalmente di alto-livello in quanto viene arricchito con i dettagli con il susseguirsi delle fasi. Infatti, le milestone potrebbero subire variazioni rispetto a quanto pianificato a causa di ritardi o imprevisti.

Analisi di dettaglio

Le attività in tale fase sono: la valutazione, in cui si revisionano i requisiti organizzando meeting con gli utenti in modo da comprendere al meglio lo stato attuale e i requisiti futuri, gli impatti dei requisiti sul sistema e le differenze rispetto al modello attuale, la progettazione del nuovo work flow in cui si definisce il processo to-be, ovvero come la soluzione verrà proposta, tenendo in considerazione l’impatto sui sistemi attuali e la revisione dove si deve confermare che i requisiti siano coerenti e integrabili all’interno del sistema, tutti i punti aperti siano adeguatamente affrontati e discussi. Tali attività vengono eseguite mediante lo svolgimento di workshop tra l’azienda cliente e il fornitore. Tale fase può durare anche diversi mesi. Possono comunque emergere diverse criticità durante tale fase, infatti, per esempio, si può non comprendere quali siano le esigenze del cliente, oppure può succedere le esigenze del cliente non sono in linea con la fattibilità del requisito, o ancora per far sì che il requisito sia implementabile.

Disegno

Nella fase di disegno, deve essere trasferita all’interno delle specifiche funzionali la presentazione della soluzione arricchita con i dettagli dell’utente. Durante tale fase è necessario assicurarsi che he la progettazione non superi i requisiti funzionali. Viene redatto il documento Specifiche funzionali, il quale ha il compito di descrivere come le implementazioni funzionano all’interno dei sistemi. In altre parole, descrivono ciò che farà il software e i suoi moduli grazie alle future implementazioni dei nuovi requisiti. Dunque, per tale fase i deliverable in input sono le specifiche funzionale in essere mentre, in output quelle aggiornate contenti le informazioni sui nuovi requisiti.

Build

Nella fase di build vengono eseguite le attività di sviluppo del codice da parte degli sviluppatori sulla base di quanto appreso all’interno delle specifiche funzionali e l’esecuzione dei system test. Dall’altro lato, Il team funzionale, in tale fase è impegnato delle attività di stesura del teskbook, infatti, per ogni requisito, vengono previsti diversi scenari di test al fine di verificarne la corretta funzionalità. Dopo avere definito tutti i possibili scenari di test, dal team funzionale viene eseguita l’attività di pianificazione dei test secondo i seguenti step: calcolo del numero di test totali, divisione del numero di test totali sulle giornate uomo disponibili per le attività, assegnazione degli scenari di test al team. Il carico di lavoro dello svolgimento dei test deve essere distribuito in modo tale da risultare maggiore all’inizio della fase di test in modo da avere la possibilità di effettuare nuovi cicli di test a causa della presenza di anomalie riscontrate durante l’esecuzione. Infine, prima dell’inizio delle attività di testing, il testbook deve essere inviato al cliente per poter essere approvato.

Test

In tale fase vengono svolti gli Integration Test. L’esecuzione dei test spetta al team funzionale. Nella casistica in cui siano presenti problematiche (bug) per i requisiti, queste vengono tracciate mediante l’utilizzo di una piattaforma di Bug Tracker in modo da mantenere tracciabilità degli errori riscontrati.

Inoltre, tale applicativo permette di fornire i dettagli dei bug individuati e consente agli sviluppatori di replicarli e di poterli risolvere. Solo dopo aver riverificato il corretto funzionamento del sistema, l’esito del test sarà considerato positivo.

UAT

Terminata la fase di test, l’attività successiva è quella degli UAT (User Acceptance Test), ovvero i test che vengono svolti insieme agli utenti per verificare il corretto funzionamento dei nuovi requisiti all’interno del sistema. Tale fase prevede solo un numero limitato di test, precedentemente definito. Per tale ragione è opportuno svolgere i test che mettono in evidenza le funzionalità primarie dei requisiti. È possibile che, durante lo svolgimento degli UAT, gli utenti possano richiedere una CR (change request) qualora il comportamento non sia in linea con quanto atteso. Le CR vengono valutate dagli sviluppatori solo una volta terminata l’attività di UAT. Qualora la CR fosse recepibile, verranno apportate le opportune modifiche ai sistemi coinvolti e successivamente testate per verificarne il corretto funzionamento. Qualora, invece, la CR non fosse recepibile o per motivi tecnici o a causa delle tempistiche stringenti per poter rieseguire tutte le attività, questa verrà censita all’interno di un documento per mantenerne la tracciabilità.

Deploy

Prima di procedere con le attività di deployment, è necessario che venga preparato un piano detto Piano di Rolloout che ha il compito di scandire le attività durante il rilascio. Tale piano deve essere approvato dal cliente. Ricevuta l’approvazione, viene effettuato, in ambiente di produzione, il deploy implementazioni sviluppate. L’attività, solitamente, si svolge in una finestra temporale al di fuori del normale orario lavorativo, in modo da avere il minor impatto possibile sui sistemi. Una volta effettuato il deploy, un membro del team funzionale esegue i sanitycheck, ovvero dei test volti a verificare che le funzionalità principali dei requisiti in ambiente di produzione siano state correttamente implementate. Qualora i sanitycheck avessero esito negativo, allora si dovrà procedere con il rollback, gli sviluppatori dovranno ripristinare in ambiente di produzione lo stato precedente e dovrà essere riprogrammata una nuova data di rilascio. Ciò comporterà, una volta individuato e risolto il problema, una nuova sessione di test al fine di verificare la corretta esecuzione delle operazioni e la pianificazione di una nuova data per poter effettuare le implementazioni richieste. Indipendente dall’esito, tutte le parti interessate dovranno essere tempestivamente informate sull’esito della fase.

Terminate le attività di deploy, le successive attività di manutenzione vengono assegnate al team di application maintenace.

Conclusioni

Il processo di realizzazione delle evolutive è terminato con il rilascio in produzione dei requisiti oggetto della release con un Go-Live posticipato rispetto a quanto pianificato. Anche se con ritardo, il desiderato dell’utente e di tutti gli attori coinvolti nelle diverse attività è risulto soddisfatto. Oltre a semplici ritardi nell’esecuzione delle attività, o al manifestarsi di CR durante la fase di UAT, la data di Go-Live della release è stata soggetta a variazione a causa di numerosi fattori. Per esempio, è stato necessario coinvolgere più fornitori esterni, i quali hanno aumentato il livello di complessità del processo. Tali fornitori, infatti, hanno avuto ritardi nello svolgimento delle attività riguardanti più requisiti. Per alcuni requisiti, è stata posticipata la data di Go-Live creando delle code della release Per un requisito, sono stato evidenziate delle problematiche che uno dei fornitori non è stato in grado di risolvere. Per tale casistica è stato adoperato un workaround, ovvero, l’utilizzo di un metodo temporaneo per raggiungere una soluzione al fine di portare il requisito in produzione. Inoltre, per una particolare implementazione, a causa di esigenze esterne, quali il recepimento di particolari direttive o leggi, al fine di evitare il rischio di incorre in sanzione, è stata necessario rilasciarla in anticipo rispetto all’interna release. Il processo descritto, è un processo che si ripete ciclicamente, infatti, ad oggi sono al vaglio dello studio di fattibilità, nuovi requisiti per evolutive future. Grazie alla possibilità di prendere parte ad un progetto nell’ambito IT, è stato possibile conoscere l’interno ciclo di vita di un software e il processo di realizzazione degli interventi di evolutive. Inoltre, l’approdo in un team di professionisti operanti nel settore da tempo ha accelerato il processo di crescita sia dal punto di vista delle competenze tecniche che tacite. Infine, l’ingresso diretto nel mondo del lavoro ha permesso di sfruttare il background accademico di questi anni e di integrarlo con nuove conoscenze e competenze acquisite nel corso del periodo di formazione che saranno fondamentali in futuro.