Requisiti non funzionali. Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.
Requisiti non funzionali. Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura. Tutti i requisiti non funzionali oggetto del presente capitolo sono da considerarsi “obbligatori” (ovvero, ATS li ritiene indispensabili per l’avvio del sistema in produzione).
Requisiti non funzionali. Le attività di assistenza e manutenzione richieste al Fornitore nel presente Capitolato Tecnico dovranno essere condotte anche nel rispetto di vincoli e requisiti non strettamente funzionali, riguardanti in generale la qualità e l’operatività del servizio.
Requisiti non funzionali. La componente hardware e software del Sistema GUS-N dovranno essere progettate e realizzate al fine di soddisfare tutti i seguenti principali requisiti non funzionali: • le componenti principali del Sistema dovranno essere installate ed attivate presso il Centro Elettronico Nazionale della Polizia di Stato sito in Napoli, nel pieno rispetto delle caratteristiche dell’infrastruttura HW/SW in esso presente, al fine di garantire una totale integrazione; • la componente sw del Sistema dovrà essere accessibile in modalità web, tramite la sola rete intranet della Polizia di Stato (Ministero dell’Interno), diffusa sul territorio nazionale; • il Sistema dovrà essere capace di garantire in esercizio la stessa fluida esperienza d’uso dell’attuale GUS, servendo circa mille utenti, di cui almeno la metà in maniera concorrente; in tale ottica, dovrà essere in grado di gestire, con tempi di risposta ragionevoli, le schede di tutti i dipendenti della Polizia di Stato in esso contenute (circa 100.000 ÷ 110.000, con un tasso di crescita annuo dell’1%), sia per le normali funzionalità di gestione che per le più evolute funzioni statistiche; • il Sistema dovrà prevedere la simultanea esistenza di un ambiente di esercizio/produzione e di un secondo ambiente di test, di ridotte capacità rispetto al primo ma funzionalmente analogo, che, un volta ultimato il progetto, verrà utilizzato per svolgere attività di formazione; questo ambiente dovrà essere in grado di servire almeno cinquanta utenti in maniera concorrente, gestendo almeno un centinaio di schede pazienti; • il Sistema dovrà essere sviluppato nel pieno rispetto del D.Lgs. 196/03, per quanto concerne il trattamento di dati sensibili tramite l’ausilio di strumenti elettronici; • le Piattaforme e gli Applicativi sw del Sistema dovranno essere interamente basate su software concesso in licenza GPL (General Public License), secondo standard non proprietari; • l’Applicativo GUS-N dovrà essere realizzato mantenendo per quanto possibile lo stesso aspetto grafico dell’applicativo GUS (interfaccia utente, UI) e riutilizzando, laddove possibile, il codice sorgente per quest’ultimo sviluppato; • l’intero Sistema dovrà essere progettato per garantire la sua totale sostenibilità per almeno tre anni (ciclo di vita del sistema) successivi alla data di positivo collaudo finale, allo scopo di evitare alla Amministrazione di dover sostenere ulteriori spese per il suo mantenimento, a parte quelle di gestione ordinaria, oltre l’investimento ...
Requisiti non funzionali. Viene richiesta la fornitura di una soluzione completa supportata da una piattaforma che permetta una gestione efficiente e resiliente per tutti gli utenti che usufruiscono del servizio. Gli operatori in particolare dovranno essere in grado di utilizzare la piattaforma sia dagli uffici sia da remoto in modalità mobile worker. Dovrà essere garantita l’interazione e la fruizione sia dai personal computer in dotazione (desktop, terminali virtuali VDI, laptop) che da dispositivi mobili. Si richiede che i client rispondano a questi requisiti minimi di compatibilità: • Sistema operativo: Microsoft Windows 10 Professional / Enterprise o superiori; • Browser: Google Chrome, Microsoft Edge; • Desktop virtuali erogati da piattaforma WMWARE Horizon versione 8.0 in modalità non persistente tramite dispositivi Praim Meridian; • Mobile: piattaforma Android. L’implementazione del Sistema, oggetto del presente capitolato, dovrà rispondere pienamente ai requisiti non funzionali di seguito dettagliati.
Requisiti non funzionali. L’Appaltatore DEVE assicurare che tutti gli interventi evolutivi realizzati risultino rispondenti ai seguenti vincoli di base degli ambienti d’ambienti d’elaborazione:
1) Hypervisor di virtualizzazione VMWare VSPHERE 5;
2) Sistema operativo: Red Hat Enterprise Linux 6;
3) Data Base: Oracle 11g , PostgreSQL 9.3;
4) Application Server / Servlet Container: JBoss 5. EAP / Tomcat 7 con JVM:
a) Sun JDK 1.6;
b) OpenJDK 1.6.19-b09; si precisa che le predette versioni sono da intendersi come di base o superiori.
Requisiti non funzionali. L’implementazione del Sistema ERP - Dyamics AX, oggetto del presente capitolato, dovrà rispondere pienamente ai requisiti non funzionali di seguito dettagliati:
A) Unicità, tracciabilità e storicizzazione di dati e documenti
B) Sicurezza, privacy e gestione utenti:
C) Integrazione, interoperabilità, aderenza agli standard
Requisiti non funzionali. Si elencano di seguito i requisiti non funzionali del sistema informativo oggetto della presente Indagine di Mercato.
Requisiti non funzionali a. La piattaforma deve essere sicura e protetta da attacchi informatici.
b. La piattaforma deve essere affidabile e disponibile 24 ore su 24, 7 giorni su 7.
c. La piattaforma deve essere scalabile per supportare un numero crescente di utenti. Affinché la piattaforma sviluppata sia efficace e soddisfi le esigenze di progetto e di tutti i beneficiari e stakeholder si prevede di avviare come prima fase di progettazione e sviluppo della piattaforma una adeguata analisi dei requisiti che, attraverso l’interazione con gli utenti del sistema, consenta di comprenderne specifiche esigenze ed aspettative. La piattaforma di interscambio e trasferimento di conoscenze sarà realizzata e personalizzata alle esigenze di progetto a partire dall’infrastruttura per l’innovazione didattica gestita dal Centro per l’e−learning dell’Università degli studi di Bari Xxxx Xxxx (Università Consorziata del CINI). Il Centro può anche svolgere azione di supporto e coordinamento alla realizzazione dei contenuti multimediali da condividere attraverso la piattaforma. L’attività 1 si articola nelle seguenti sottoattività:
1.1 Analisi dei requisiti della piattaforma di progetto. Nell'ambito di questa sottoattività, il CINI si confronterà con i principali partner del progetto per verificare e validare che i requisiti della piattaforma siano coerenti con le esigenze del progetto e dei suoi stakeholder.
Requisiti non funzionali. La SOLUZIONE deve essere rispondente ai seguenti vincoli e requisiti non funzionali:
1) deve essere compatibile con i seguenti vincoli d’ambiente tecnologici del SIR della Regione Lazio:
a) Hypervisor di virtualizzazione VMWare VSPHERE 5;
b) Sistema operativo: Red Hat Enterprise Linux 6;
c) Data Base: Oracle 11g , PostgreSQL 9.3;
d) Application Server / Servlet Container: JBoss 5. EAP / Tomcat 7 con JVM:
i) Sun JDK 1.6;
ii) OpenJDK 1.6.19-b09; si precisa che la SOLUZIONE deve essere compatibile con le predette versioni o con versioni superiori.
2) la SOLUZIONE deve inoltre assicurare:
a) la registrazione di identità digitali in quantità illimitata;
b) la configurazione di ambienti in alta affidabilità almeno per componente di Access Management;
c) adeguati tempi di risposta per le funzioni d’accesso alle risorse protette con un carico concorrente di almeno 10.000 utenti contemporanei;
3) le licenze software della SOLUZIONE devono permettere la predisposizione di un’ambiente di produzione, conforme ai requisiti di cui al punto precedente, e di un ambiente di collaudo speculare alla produzione. Si precisa infine che la SOLUZIONE offerta deve essere fornita dall’Appaltatore in licenza d’uso, anche non esclusiva, illimitata (per traffico, utenze, volumi trattati, CPU) e di durata perpetua.