Attività: A4 Test e sperimentazione

Transcript

1 UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO, IL LAVORO E L INNOVAZIONE "Apulian ICT Living Labs" P.O. FESR Puglia Asse I - Linea di Intervento Azione Dominio di riferimento: Inclusione Sociale e Invecchiamento Attivo e in Salute Progetto: GEMACA GEstione e Monitoraggio degli Aiuti ai poveri mediante Carta Acquisti Attività: A4 Test e sperimentazione Deliverable: Versione 1.0 Data 31/07/2014 Autore SOFTWARE DESIGN S.R.L. SVN Pag. 1

2 Storico modifiche Data Versione Autore Descrizione 31/07/ SOFTWARE DESIGN S.R.L. Documenti correlati Nome Descrizione Versione Pag. 2

3 Sommario SCOPO DEL DOCUMENTO INTRODUZIONE SCENARIO A: REGISTRAZIONE ENTE SCENARIO B: REGISTRAZIONE UTENTE SCENARIO C: MONITORAGGIO ASSISTITI E AIUTI EROGATI SCENARIO D: APERTURA TICKET DI ASSISTENZA SCENARIO E: ESERCIZIO CARTA ACQUISTI COME ENTE CONVENZIONATO SCENARIO F: ESERCIZIO CARTA ACQUISTI COME UTENTE FINALE Pag. 3

4 Scopo del documento Obiettivo di questo documento è quello di descrivere il piano di test ed il relativo report espresso in termini di raccomandazioni di miglioramento del prototipo. Introduzione Il test del prototipo funzionale ha avuto lo scopo di verificare e validare le funzioni interattive del Portale Web e della Mobile App. Gli scenari di test sono stati sperimentati e validati sia in laboratorio, durante la fase di test funzionale, sia dal vivo, durante la vera e propria fase di sperimentazione condotta nell ambito delle attività del BANCO DELLE OPERE DI CARITÀ, per quanto concerne gli aspetti relativi al monitoraggio degli assistiti e degli aiuti erogati, e nell ambito delle attività del Banco di Abbigliamento Solidale gestito da EQUANIMA, per quanto concerne l utilizzo della Carta Acquisti. Di seguito sono indicati gli scenari nell ambito dei quali è stata condotta la sperimentazione e le relative raccomandazioni utente. 1 Scenario A: Registrazione Ente - Registrazione ente: è stato sperimentato e validato il form di acquisizione dei dati di registrazione dell ente, sulla base del quale vengono attribuite le credenziali di accesso (login, password); - Modifica: è stato sperimentato e validato il form di modifica della password e dei dati anagrafici dell ente. 1 - La procedura di registrazione è funzionale ma il form di compilazione, sebbene richieda poche informazioni, risulta essere eccessivamente macchinoso poiché prevede una procedura composta da un alto numero di operazioni sequenziali: creazione profilo, creazione ruolo, creazione gruppo, creazione utente e inserimento nell anagrafica enti. - Si raccomanda l introduzione di una guida che ricordi all utente l ordine delle operazioni da seguire per completare la procedura o anche soltanto una disposizione delle voci di menù che rispetti il suddetto ordine. Allo scopo di impedire eventuali inconsistenze dovute ad erronee associazioni tra gli elementi dei vari step (profilo, ruolo, gruppo e utente), si raccomanda la rappresentazione grafica (per es. sotto forma di albero) delle associazioni mano a mano che le stesse sono definite. 2 - La cancellazione di un ente avviene mediante la successiva eliminazione dello stesso da o- gni step (profilo, ruolo, gruppo e utente) con un operazione che risulta essere estremamente complessa. Pag. 4

5 - Si raccomanda l introduzione di una operazione di cancellazione di un ente che consenta l eliminazione simultanea dello stesso da ogni step. 2 Scenario B: Registrazione Utente - Registrazione utente: è stato sperimentato e validato il form di inserimento dei dati di un nuovo assistito; - Attribuzione della relazione di parentela: è stata sperimentata e validata la funzione di attribuzione della relazione di parentela fra utenti già registrati all interno del sistema. - Il form di registrazione è intuitivo e contiene pochi campi obbligatori. Ciò facilita sicuramente l operazione di data entry in fase di registrazione ma in fase di monitoraggio rischia di offrire un database povero di informazioni importanti sotto il profilo statistico e di avere schede anagrafiche incomplete. - Si raccomanda l introduzione di un Alert che segnali la percentuale di completamento dei dati richiesti dal form di registrazione. 3 Scenario C: Monitoraggio Assistiti e Aiuti erogati - Ricerca utente: è stato sperimentato e validato il form di ricerca, tramite codice fiscale, di un nominativo all interno del sistema e la corretta apertura della relativa scheda anagrafica in caso di assistito in carico all ente richiedente; - Registrazione aiuti: è stata sperimentata e validata la scheda di registrazione della tipologia di fabbisogno e delle prestazioni erogate. - Alcune versioni di Internet Explorer non segnalano l esistenza di un utente già registrato nel database da un altro ente causandone la duplicazione. - Si raccomanda la pubblicazione di un messaggio da parte del sistema che suggerisca l utilizzo dei browser Google Chrome e Firefox. 4 Scenario D: Apertura Ticket di Assistenza - Richiesta assistenza: è stato sperimentato e validato il form tramite il quale un ente può richiedere assistenza; - Invio è stata sperimentata e validata la procedura di invio e ricezione della all indirizzo prestabilito. Pag. 5

6 Apulian ICT Living Labs - Il sistema non segnala all amministratore l apertura di un nuovo ticket. - Si raccomanda la predisposizione di un meccanismo che preveda la comunicazione di apertura di un nuovo ticket tramite l inoltro di una ad un indirizzo predefinito. 5 Scenario E: Esercizio Carta Acquisti come Ente convenzionato - Download della Mobile App: è stato sperimentato e validato il form di presentazione e download della Mobile App del sistema; - Autenticazione: è stato sperimentato e validato il form di autenticazione/login di un ente convenzionato; - Gestione convenzioni: è stata sperimentata e validata la creazione di una nuova convenzione attraverso la compilazione del relativo form di specificazione della categoria merceologica (tipologia di saldo), del prodotto (codice prodotto) e del corrispondente valore (punti spesa). - Rilascio Carta Acquisti: è stato sperimentato e validato il form di inserimento di una nuova Carta Acquisti rilasciata a un utente registrato nel sistema; - Ricarica: è stato sperimentato e validato il form (movimenti card) di accredito di uno o più borsellini elettronici associati a una Carta Acquisti; - Transazione: è stato sperimentato e validato il form (movimenti card) di decurtazione dei punti spesa corrispondenti al valore dei beni/servizi acquistati dal relativo borsellino elettronico; - Verifica saldo punti: è stata sperimentata e validata la funzione di visualizzazione del saldo punti del titolare della Carta Acquisti. - L installazione dell App richiede l impostazioni di alcuni flag sul proprio smartphone in quanto non è disponibile sugli store ufficiali delle App. Inoltre l App è disponibile soltanto per piattaforma Android. - Non avendo intenzione di rendere pubblica la App, si raccomanda almeno la sua predisposizione per la piattaforma IOS. 6 Scenario F: Esercizio Carta Acquisti come Utente finale - Rilascio ed esercizio Carta Acquisti fisica: è stata sperimentata la funzionalità di verifica di una richiesta di Carta Acquisti e la modalità di rilascio contestuale della corrispondente Carta Acquisti fisica presso un distributore autorizzato; Pag. 6

7 - Verifica posizione: è stata sperimentata e validata la funzione di visualizzazione del saldo punti e ultimi movimenti del titolare della Carta Acquisti. - Nessun feedback critico rilevato. Pag. 7