Processo di realizzazione delle evolutive del software in azienda

Sistemi coinvolti nel processo

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:

1. Tecnico: si indaga la possibilità di sviluppare tecnicamente il requisito
2. 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 dello 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.

Conclusioni

Il processo di realizzazione delle evolutive termina con il rilascio in produzione dei requisito 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à, possono manifestarsi CR durante la fase di UAT, e la data di Go-Live della release è soggetta a variazione a causa di numerosi fattori.

D’altro canto, per alcuni requisiti, può essere posticipata la data di Go-Live creando delle code della release. 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, può essere necessario rilasciare in anticipo rispetto all’interna release.

Infine, bisogna dire che il processo descritto, è un processo che si ripete ciclicamente, infatti, ad prima di concludere un rilascio sono già al vaglio dello studio di fattibilità, nuovi requisiti per evolutive future.