Allegato Scheda di assessment dell'applicativo
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVW
1
2
SCHEDA DI ASSESSMENT DELL' APPLICATIVO
3
4
NOME DELL'APPLICATIVO[Nome dell'applicativo]
5
SERVIZI SUPPORTATI[Elenco servizi supportati]
6
7
Aspetti Tecnologici
8
Stack tecnologicoElencare le componenti tecnologiche attualmente in uso, ad es. database usato e rispettiva versione, ambiente di runtime, sistemi di notifica, sistemi di gestione di code, web server
9
Uso di componenti sostituibili con l'equivalente servizio cloud-nativeElencare le componenti on-premise utilizzate dall'applicativo che sono sostituibili con servizi gestiti dal cloud provider, ad es. database, LDAP, load balancer, SMTP server
10
Dimensionamento delle componenti infrastrutturaliElencare le componenti infrastrutturali attualmente in uso che garantiscono il corretto funzionamento dell'applicativo, ad es. # di server, dimensione dello storage, CPU, memoria
11
Utilizzo effettivo delle componenti infrastrutturaliDescrivere l'utilizzo effettivo delle risorse sulla base di misurazioni effettive o stime
12
Dipendenza dall'hardware fisicoDescrivere la situazione attuale in cui l'applicativo si trova in termini di dipendenza dall’hardware fisico, specificando ad esempio se si usano macchine virtuali, container oppure se l'applicativo o parti di esso sono su macchine fisiche
13
Misure di sicurezzaDescrivere a quali minacce l'applicativo è esposto, specificando quali componenti e dati sono più vulnerabili e richiedono protezione
14
Sistemi on-premise da cui dipendeElencare i sistemi on-premise interni ed esterni da cui l'applicativo dipende, es. IDP, LDAP, sistema di notifiche. Non specificare sistemi già in cloud, come le piattaforme abilitanti della PA ( ad es. Spid, PagoPA)
15
Sistemi on-premise che dipendonoElencare i sistemi on-premise interni ed esterni che dipendono dell'applicativo, ad es. i sistemi che consumano i dati dell'applicativo
16
17
Vincoli Tecnologici
18
Presenza di test di validazioneSpecificare la presenza di test che possano validare le eventuali modifiche da effettuare sul codice sorgente per ridurre il rischio di regressione (ad es. test unitari, di integrazione, funzionali, performance). Per un approfondimento su questa tipologia di test vedi capitoli 5.5 e 6.4
19
Modificabilità del codice sorgenteSpecificare se si può modificare il codice sorgente in modo completo, ad es. in quanto se ne ha la proprietà o se la licenza del codice sorgente lo permette (es. open source), o parziale, ad es. influenzando le scelte evolutive del prodotto realizzato da terze parti
20
Disponibilità di documentazione tecnicaSpecificare la documentazione tecnica disponibile che spiega il funzionamento interno dell'applicativo e delle sue componenti per intervenire in modo mirato e controllato. Vedi capitolo 4.3.2.2
21
Connettività minima necessariaConsiderando l'impatto della connettività (latenza, bandwidth) sull'usabilità dell'applicativo in relazione agli SLA che il fornitore deve garantire, specificare se l'accesso alla rete locale è un requisito vincolante all'usabilità di questo applicativo
22
23
Dati
24
Dimensione della base datiRiportare la dimensione dei dati da migrare nell'unità di misura opportuna fra Byte, KB, MB, GB, TB, ecc.
25
Frequenza di consultazione dei dati (annuale)Specificare ogni quanto i dati vengono consultati nell’arco di un anno
26
Frequenza di aggiornamento dei dati (annuale)Specificare ogni quanto i dati vengono aggiornati nell’arco di un anno
27
Ciclo di vita dei datiRiportare la quantità di tempo dopo la quale il dato può essere considerato obsoleto e quindi eliminabile dal sistema. Seguire le indicazioni di data retention del GDPR laddove applicabili. Differenziare per tipologia di dato se necessario
28
Applicativi che trattano gli stessi datiConsiderare gli applicativi che trattano gli stessi dati gestiti da questo applicativo (tutti o un sottoinsieme). In particolare, si fa riferimento a quegli applicativi che hanno una copia dell'insieme di dati considerato e che necessitano una sincronizzazione. Riportare i nomi degli applicativi e il sottoinsieme di dati
29
30
Parti interessate
31
Rappresentanti delle aree impattateRappresentanti delle Aree ImpattateElencare le persone da coinvolgere o da tenere informate sia perchè con potere decisionale, sia perché utilizzatrici dell'applicativo o perché impattate dalla migrazione. Considerare un eventuale coinvolgimento di personale esterno all'amministrazione (es. fornitori con un'influenza sulla migrazione). Indicare per ognuno: nome, cognome, ruolo e se va coinvolto o informato
32
Processi impattati e punti di attenzioneRiportare i processi interni o esterni dell'organizzazione che vengono impattati da questo applicativo e se vi sono dei punti d'attenzione da considerare durante il processo di migrazione
33
Bisogni
34
# medio di utenti unici giornalieri negli ultimi 12 mesiSpecificare il numero medio di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics
35
# massimo di utenti unici giornalieri negli ultimi 12 mesiSpecificare il numero massimo di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics
36
# minimo di utenti unici giornalieri negli ultimi 12 mesiSpecificare il numero minimo di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics. Se ci sono giorni in cui l'applicativo è inutilizzato o spento mettere "0" come valore
37
Periodi di utilizzo in una settimanaIdentificare in quali fasce orarie il servizio è utilizzato in una settimana. Evidenziare eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l'utilizzo è mediamente costante nell'arco della giornata e della settimana indicare "utilizzo omogeneo"
38
Periodi di utilizzo in un meseIdentificare in quali fasce orarie il servizio è utilizzato in un mese. Evidenziare eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l'utilizzo è mediamente costante nell'arco del mese indicare "utilizzo omogeneo"
39
Periodi di utilizzo in un annoIdentificare in quali fasce orarie il servizio è utilizzato in un anno. Evidenziare eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l'utilizzo è mediamente costante nell'arco dell'anno indicare "utilizzo omogeneo"
40
Costi dell'infrastrutturaIdentificare i tempi ed i costi per l'allestimento, la manutenzione dell'infrastruttura attuale ed il suo eventuale potenziamento (provisioning di nuove risorse)
41
LicenzeLicenzeElencare quali licenze sono utilizzate, il loro costo e quando scadono considerando per il riuso https://docs.italia.it/italia/developers-italia/lg-acquisizione-e-riuso-software-per-pa-docs/it/bozza/
42
CriticitàDescrivere se esistono aspetti critici dell'applicativo, ad esempio:
- performance o stabilità che impattano l'operatività degli utenti finali o richiedono una spesa specifica per la loro risoluzione temporanea (perché una definitiva non è attualmente possibile)
- conformità normativa, ad esempio GDPR
- sicurezza
43
Evoluzione del servizio nei prossimi 3 anniDescrivere le aree di evoluzione previste o ipotizzate per il servizio supportato dall'applicativo per identificare la centralità rispetto alla strategia dell'organizzazione. Tenere in considerazione, nel caso disponibili, i piani pluriennali definiti ed eventuali scadenze già definite. Considerare la tipologia e la numerosità delle evoluzioni attese per l'applicativo
44
45
Mercato
46
Alternative SaaSCloud marketplace AgIDConsultare il cloud marketplace di AgID per individuare la presenza di alternative SaaS per l'applicativo in questione.
47
Disponibilità di import dei datiAllo scopo di consentire la migrazione da un altro fornitore SaaS o servizio SaaS, il fornitore SaaS deve garantire all’acquirente la possibilità di importare i dati all’interno del servizio SaaS tramite formati pubblici e aperti. Indicare qui se la garanzia è presente
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...