Ciclo di vita del software. Il ciclo di vita dei moduli applicativi e di tutti gli item ad essi collegati (es.: sorgenti, file di configurazione, etc.) sono gestiti utilizzando il sistema di controllo di versione interno alla CSEA (GIT). Tutti gli oggetti realizzati in fase di intervento, le nuove funzionalità richieste nella fornitura, le modifiche a quelle già realizzate, e la documentazione interna al codice e i relativi documenti allegati, devono essere conservati e costantemente aggiornati nel sistema di controllo di versione.
Ciclo di vita del software. Per le attività di sviluppo software l’aggiudicatario dovrà adottare un modello di tipi iterativo-prototipale, con un ampio coinvolgimento dell’Amministrazione per la condivisione dei requisiti e delle scelte progettuali. Il ciclo di vita dovrà prevedere le seguenti fasi, da eseguirsi iterativamente a seguito di approvazione da parte dell’Amministrazione: ⮚ raccolta e analisi dei requisiti ⮚ progettazione ⮚ prototipazione ⮚ implementazione ⮚ testing ⮚ aggiornamento della documentazione ⮚ rilascio L’analisi dei requisiti dovrà comprendere la predisposizione di documenti di specifiche e di mock-up che illustrino i dettagli delle interfacce utente per l’approvazione preliminare dell’amministrazione. Gli strumenti saranno indicati dalla stazione appaltante in fase esecutiva (presumibilmente MockFlow); l’aggiudicatario dovrà acquisire la licenza necessaria all’utilizzo di tale strumento. Gli sviluppi dovranno avvenire in appositi ambienti di sviluppo predisposti dall’aggiudicatario presso le proprie sedi. L’approvazione definitiva avverrà a seguito del rilascio in staging e delle successive verifiche da parte della stazione appaltante. I test funzionali saranno di due tipi: quelli a carattere esaustivo eseguiti dall’aggiudicatario e quelli sulle funzionalità principali da eseguirsi da parte dell’Amministrazione (UAT – User Acceptance Test), anche sulla base dei piani di test predisposti dall’aggiudicatario. Resta ferma la facoltà dell’Amministrazione di eseguire dei test ulteriori rispetto a quelli previsti dai piani di test. Dovranno essere predisposti degli strumenti per l’esecuzione automatica dei test di non regressione, dall’aggiudicatario in occasione di ogni rilascio. I test di non regressione dovranno essere eseguiti in ambiente di staging e, laddove possibile, in ambiente di produzione. In offerta tecnica dovranno essere descritti gli strumenti e la metodologia che saranno utilizzati. Gli sviluppi dovranno essere ottimizzati anche dal punto di vista delle performance (in particolare tempi di risposta percepiti dall’utente). Il rilascio di eventuali funzionalità che richiedano, anche sulla base dell’incremento del numero di utenti del sistema conseguente al rilascio della nuova funzionalità), un rafforzamento delle risorse infrastrutturali, dovrà preventivamente essere comunicato alla stazione appaltante congiuntamente al nuovo dimensionamento necessario. A seguito dei rilasci più impattanti dovranno essere rieseguiti in ambiente di staging i performanc...