Sapienza Università di Roma
Centro InfoSapienza
Piazzale Aldo Moro,5 – 00185 Roma
www.uniroma1.it
Università degli Studi di Roma
“La Sapienza”
Centro InfoSapienza
GARA PABS 100
CAPITOLATO TECNICO
“PROCEDURA APERTA
PER L’APPALTO DEI SERVIZI DI MANUTENZIONE
DEL SISTEMA INFORMATIVO STUDENTI – INFOSTUD"
(CIG 067790728D)
Università La Sapienza di Roma – Capitolato di Gara
Indice
1 Premessa ................................................................................................................... 1
2 Descrizione del contesto .............................................................................................. 2
2.1 SIAD ......................................................................................................................................... 2 2.2 GOMP ...................................................................................................................................... 3 2.3 PIANI DI STUDIO ..................................................................................................................... 5 2.4 INFOSTUD ............................................................................................................................... 5
2.4.1 Utenti del sistema ..................................................................................................... 5 2.4.1.1 Segreterie Amministrative ......................................................................... 6 2.4.1.2 Studenti ..................................................................................................... 6 2.4.1.3 Docenti ...................................................................................................... 6 2.4.1.4 Segreterie didattiche .................................................................................. 7 2.4.1.5 Altri............................................................................................................. 7
2.4.2 Stato dell’arte ............................................................................................................ 7 2.4.2.1 Numero Utenti del Sistema ....................................................................... 7 2.4.2.2 Numero di operazioni effettuate dalle funzioni applicative delle
segreterie amministrative nell’anno solare 2010. ...................................... 8 2.4.2.3 Registrazione Studenti da Web anno 2010. .............................................. 9 2.4.2.4 Numero Corsi e Concorsi attivi per l’anno accademico 2009/2010 .......... 9 2.4.2.5 Numero Bollettini stampati e pagati per l’anno 2010 .............................. 10 2.4.2.6 Numero Certificati stampati per l’anno 2010 ........................................... 11 2.4.2.7 Numero Laureati e stampa Pergamene anno 2010 ................................ 12 2.4.2.8 Verbalizzazione degli esami .................................................................... 12 2.4.2.9 Numero Studenti regolari e non regolari anno accademico 2010 ........... 12
2.4.3 INFRASTRUTTURA IT ........................................................................................... 13 2.4.3.1 Software applicativo: ............................................................................... 13 2.4.3.2 Ambiente di esercizio .............................................................................. 14 2.4.3.3 Ambiente Test ......................................................................................... 16 2.4.3.4 Ambiente di sviluppo ............................................................................... 16
2.5 ORGANIZZAZIONE UNIVERSITA‟ LA SAPIENZA ................................................................ 18 2.5.1 La manutenzione dell’infrastruttura tecnologica ..................................................... 18 2.5.2 Manutenzione del software ..................................................................................... 18 2.5.3 Help Desk e supporto utenti ................................................................................... 19 2.5.4 Gestione applicativa e base dati ............................................................................. 19
3 Descrizione della fornitura .......................................................................................... 21
3.1 Servizi di Manutenzione correttiva ......................................................................................... 21 3.1.1 Dimensionamento ................................................................................................... 22 3.1.2 Composizione dei Gruppi di Lavoro ........................................................................ 22
3.2 Servizi di Manutenzione Adeguativa ...................................................................................... 23 3.2.1 Dimensionamento ................................................................................................... 23 3.2.2 Composizione dei Gruppi di Lavoro ........................................................................ 24
3.3 Servizi di Manutenzione Evolutiva ......................................................................................... 24 3.3.1 Descrizione Requisiti .............................................................................................. 24
3.3.1.1 Manutenzione evolutiva sul sistema Infostud ................................................ 24 3.3.1.2 Integrazione Infostud in U-GOV ................................................................. 25
3.3.2 Dimensionamento ................................................................................................... 27
Università La Sapienza di Roma – Capitolato di Gara
3.3.3 Composizione dei Gruppi di Lavoro ........................................................................ 27 3.4 Servizi di Assistenza utenti e help desk ................................................................................. 28
3.4.1 Dimensionamento ................................................................................................... 29 3.4.2 Composizione dei Gruppi di Lavoro ........................................................................ 29 3.4.3 Orari assistenza utenti e help desk ......................................................................... 30
3.5 Servizi di gestione applicativi e Basi Dati ............................................................................... 30 3.5.1 Descrizione requisiti ................................................................................................ 30
3.5.1.1 Piccoli Interventi ........................................................................................ 31 3.5.1.2 Prodotti/servizio ......................................................................................... 31 3.5.1.3 Back-end ................................................................................................... 31
3.5.2 Dimensionamento ................................................................................................... 32 3.5.3 Composizione dei Gruppi di Lavoro ........................................................................ 33
4 Modalità di esecuzione ............................................................................................... 34
4.1 Modalità di esecuzione dei servizi e delle attività .................................................................. 34 4.1.1 Modalità progettuale ............................................................................................... 34
4.1.1.1 Manutenzione evolutiva e manutenzione adeguativa ............................. 35 4.1.2 Modalità continuativa .............................................................................................. 39
4.1.2.1 Manutenzione Correttiva ......................................................................... 39 4.1.2.2 Assistenza Utenti e Help Desk ................................................................ 40 4.1.2.3 Gestione applicativi e Basi Dati ............................................................... 40
4.2 Orario di Lavoro ...................................................................................................................... 41 4.2.1 Verifica della presenza............................................................................................ 41 4.2.2 Luogo di lavoro ....................................................................................................... 41
5 Livelli di Servizio ......................................................................................................... 42
5.1 Definizioni per la misura del livello di servizio ........................................................................ 42 5.1.1 Classi di gravità ....................................................................................................... 43
6 Presa in carico e trasferimento ................................................................................... 45
6.1.1 Presa in carico ........................................................................................................ 45 6.1.2 Trasferimento di know-how ..................................................................................... 45
7 Profili professionali richiesti ........................................................................................ 46
8 Allegati al presente capitolato tecnico......................................................................... 50
Università La Sapienza di Roma – Capitolato di Gara pag. 1
1 Premessa
Il presente capitolato ha lo scopo di definire i requisiti relativi alla fornitura dei
servizi in oggetto, in quantità, qualità e livelli di servizio adeguati allo sviluppo,
mantenimento ed utilizzo del Sistema informatico per la gestione amministrativa e
didattica delle carriere degli studenti, denominato Infostud.
Con il termine “Ateneo” va intesa l‟Università degli Studi di Roma “La Sapienza”
Con il termine “Fornitore” va intesa l‟Impresa aggiudicataria della fornitura.
Con il termine “Amministrazione” vanno intesi gli uffici dell‟Amministrazione
Centrale dell‟Ateneo.
Con il termine “Infosapienza” va intesa la struttura organizzativa che eroga i
servizi applicativi gestionali all‟interno dell‟Ateneo.
Quando non diversamente specificato, con “capitolato” si intende il presente
documento, con “gara” si intende la gara da effettuare a fronte del capitolato, con
“contratto” si intende il contratto che verrà sottoscritto a seguito
dell‟aggiudicazione della gara, con “fornitura” si intende il complesso delle
attività e dei prodotti che il Fornitore è chiamato a compiere e a produrre per
onorare il contratto.
L‟oggetto della fornitura è descritto nel capitolo 3, con lo scopo di definire a
grandi linee i servizi richiesti indicandone anche i parametri quantitativi, le figure
professionali e la composizione dei gruppi di lavoro, mentre nel capitolo 4 sono
descritte le modalità di esecuzione dei servizi e delle attività, i prodotti della
fornitura nonché i relativi aspetti qualitativi.
E parte integrante del capitolato l‟allegato “U-GOV Architettura, tecnologia e
applicazioni White Paper Luglio 2007 - Cineca”.
Per la descrizione della struttura organizzativa, delle competenze e della
dislocazione degli uffici dell‟Ateneo si rimanda al sito www.uniroma1.it.
Università La Sapienza di Roma – Capitolato di Gara pag. 2
2 Descrizione del contesto
Il sistema Informativo integrato d‟Ateneo: la scelta di UGov.
L'integrazione ed il coordinamento dei dati in una (grande) organizzazione è parte
essenziale di quello che viene chiamato "data governance", ovvero l'insieme dei
principi, tecniche e processi che l'organizzazione adotta per esercitare un controllo
totale del contenuto e della gestione delle fonti informative facenti capo alla
organizzazione stessa.
A partire da tali considerazioni, La Sapienza, tra le linee di indirizzo, ha rilevato
come prioritaria la realizzazione di un sistema informativo integrato. Il processo
per raggiungere l‟obiettivo di integrazione dei diversi sistemi informatici, vista la
grandezza e la numerosità delle strutture universitarie, è lungo e complesso.
La modalità per affrontare il problema è stata quella di procedere per macro fasi,
iniziando dalla imprescindibile fase preliminare della rilevazione presso le
strutture universitarie delle applicazioni e delle basi di dati esistenti e la
successiva determinazione dei nuovi requisiti del sistema informativo.
Le attività che hanno costituito il punto di partenza per l‟individuazione del
sistema informativo integrato sono state: censimento delle applicazioni esistenti e
delle corrispondenti basi di dati; mappa delle interrelazioni tra applicazioni, basi
di dati ed identificazione dei flussi informativi tra applicazioni e basi di dati;
identificazione di eventuali duplicazioni/sovrapposizioni di funzionalità e/o basi
dati; determinazione dei nuovi requisiti utente; ecc.
La scelta di indirizzo dell‟Ateneo della soluzione tecnologica è stata quella di
UGov del Consorzio Cineca, e influenzerà in maniera sostanziale la gestione di
dati e processi dell‟Ateneo nei prossimi anni. Il sistema UGov si compone di aree
funzionali e moduli ed offre una copertura delle aree amministrative dell‟Ateneo.
Sono attualmente in corso i progetti relativi all‟integrazione in UGov riguardo i
sistemi per la gestione Contabile, la gestione Giuridico Amministrativa e la
Ricerca. Inoltre è in corso la realizzazione del portale, sempre in ottica UGov.
Relativamente all‟area Didattica e Studenti, il sistema UGov prevede due
applicazioni che, nell‟attuazione presso la Sapienza, sono costituiti dal sistema
d‟Ateneo SIAD.
2.1 SIAD
Il SIAD (Sistema informativo Integrato d‟Ateneo per la Didattica) è il sistema di
gestione della programmazione didattica e delle carriere amministrative degli
studenti, la cui base di dati dovrà confluire anch‟essa in UGov.
Le caratteristiche principali sono:
punto unico di inserimento delle informazioni, che vengono poi
automaticamente trasferite agli altri sistemi secondo le necessità;
Università La Sapienza di Roma – Capitolato di Gara pag. 3
gestione integrata dei Manifesti, della conseguente programmazione
didattica e delle carriere degli studenti nel rispetto delle norme di legge ed
in conformità agli ordinamenti ed all‟offerta didattica dichiarati al MIUR;
gestione di tutti i corsi di laurea riformati ai sensi del D.M. 270/2004 e
succ.
Figura 1 - SIAD
Come illustrato in Figura 1, il SIAD si compone dei seguenti principali moduli
applicativi: Gomp, Piani di Studio1 ed Infostud.
2.2 GOMP
L‟applicativo GOMP consente la composizione e gestione di tutti i Corsi di
Laurea che si conformano secondo il DM270/04, ed inoltre è in grado di definire,
popolare, gestire e validare i piani di studio degli studenti.
In base alla logica di collaborazione applicativa, per ogni Anno Accademico (a
partire dal 2009-2010) e per ogni corso di Laurea, si importano in GOMP tutti i
1 L‟applicativo Piani di Studio potrebbe essere rinominato in Percorso Formativo.
Università La Sapienza di Roma – Capitolato di Gara pag. 4
dati che compongono il RAD (Regolamento Didattico di Ateneo) e l‟Offerta
Formativa, ossia tutto ciò che è pubblicato dal MIUR su http://offf.miur.it.
Tale operazione consente l‟inserimento automatico in GOMP di tutti i Corsi di
Laurea, ognuno con il proprio Ordinamento Didattico e le proprie regole di
adeguamento al DM 270/04 che fungono da fondamenta e da controllo per la
validazione dei Manifesti e delle Programmazioni Didattiche.
Nell‟ambito del SIAD, Gomp coopera con Infostud sia tramite l‟ausilio di servizi
web che con scambi manuali di flussi di dati. L‟inserimento di un nuovo
insegnamento, ad esempio, avviene in cooperazione applicativa con Infostud
seguendo la procedura di creazione e richiesta codifica: solo dopo l‟assegnazione
del codice si potrà utilizzare l‟insegnamento nel manifesto.
I manifesti sono validati rispetto all‟ordinamento attraverso 3 livelli di controllo:
1° livello – controllo quadratura con ordinamento fino ai CFU previsti per i
sottogruppi di ambito e agli SSD obbligatori e non
2° livello – controlli formali sulla correttezza del contenuto
3° livello – a livello locale, regole di Ateneo implementate ad hoc
Figura 2 - Infrastruttura GOMP
Uno schema dell‟infrastruttura GOMP è mostrato in Figura 2.
Università La Sapienza di Roma – Capitolato di Gara pag. 5
2.3 PIANI DI STUDIO
L‟applicativo Piani Di Studio consentirà agli studenti la presentazione dei loro
piani di studio o meglio la definizione del loro percorso formativo in modo
congruente al manifesto degli studi ed alle ulteriori regole che ateneo, facoltà e/o
corsi di laurea avranno stabilito.
Piani Di Studio è un modulo aggiuntivo che sia appoggia a GOMP tramite il quale
è automaticamente popolato con i quadri e relative regole già presenti nell‟offerta
formativa del corso di studio.
I sistemi Infostud e Piani di Studio opereranno in collaborazione applicativa per
l‟importazione dei dati anagrafici e delle carriere degli studenti e per la verifica
delle carriere studenti esistenti (limitatamente ai corsi DM 270).
2.4 INFOSTUD
Il sistema Infostud è la tecnologia a servizio della Sapienza per la gestione delle
carriere amministrative e didattiche degli studenti. In questo ambito offre i propri
servizi agli Studenti, ai Docenti ed al Personale tecnico-amministrativo.
Nasce nel 2001 per sostituire il vecchio sistema informatico e per rispondere alle
novità introdotte dal DM 509/99 e successivi DM sulle classi di laurea e lauree
specialistiche.
Attualmente gestisce le carriere degli studenti iscritti a corsi di laurea di vecchio
ordinamento, DM 509/1999 e DM 270/2004 e succ.
Infostud permette la gestione integrata delle carriere, svolte dallo studente alla
Sapienza, in tutte le fasi della filiera Registrazione – Concorso -
Immatricolazione/Iscrizione - Esami di profitto – Certificazione – Laurea –
Stampa Pergamena per i corsi di Studio di primo e secondo livello, gli eventuali
post-laurea (Master, Scuola di specializzazione, Esame di Stato, Dottorato di
Ricerca), oltre che per i corsi di Formazione ed Alta Formazione.
Lo studente, all‟interno del Sistema Infostud, è censito con il codice fiscale e
riconosciuto univocamente dalla sua matricola, che è unica nell‟arco della sua
permanenza alla Sapienza e per qualunque tipologia di iscrizione (corsi di laurea e
post lauream), con una divisione logica delle carriere.
E‟ possibile accedere ad Infostud disponendo di un utenza e delle credenziali per
l‟accesso (matricola e password) e, di un browser ed un collegamento ad internet.
Tutte le funzioni disponibili in Infostud sono assegnabili agli utenti secondo un
sistema di profilazione.
2.4.1 Utenti del sistema
Università La Sapienza di Roma – Capitolato di Gara pag. 6
2.4.1.1 Segreterie Amministrative
Le segreterie amministrative dispongono delle funzioni necessarie allo
svolgimento delle attività di gestione delle carriere studenti, nel rispetto delle
regole previste dalla legge, dal Manifesto degli Studi e dai Regolamenti d‟Ateneo.
Le funzioni sono state assegnate agli uffici secondo diversi profili d‟utenza,
standard e/o individuale, e con differenti viste sui dati di competenza.
Infostud consente alle segreterie amministrative di gestire la carriera
amministrativa e didattica dello studente in tutte le complesse fasi della filiera,
dalla registrazione fino alla richiesta di stampa della pergamena.
Gli utenti di segreteria amministrativa sono divisi in 8 diversi profili principali
(segreterie, master, specializzazione, borse di studio, dottorati di ricerca, esami di
stato, offerta formativa, ciao).
2.4.1.2 Studenti
Gli studenti utilizzano Infostud come uno sportello di segreteria virtuale dal quale
è possibile, dopo la registrazione al sistema, svolgere vari atti amministrativi,
come ad esempio presentare domanda di concorso, verificare l‟ammissione ai
corsi, presentare domanda di borsa di studio per l‟esonero delle tasse e stampare le
tasse di iscrizione/immatricolazione, con funzioni specifiche per i diversi corsi (1
e 2 livello, master, specializzazione, dottorati, esami di stato) e con dinamicità dei
controlli. Quest‟ultimi sono variabili secondo le diverse situazioni amministrative
e didattiche nelle quali lo studente può trovarsi nel corso del tempo.
Lo studente può, inoltre, prenotarsi agli esami e verificare gli esiti degli stessi,
inserire dichiarazioni personali (ad esempio reddito, titoli di studio, esenzioni,
recapito) o semplicemente verificare la propria iscrizione.
Infine, lo studente può stampare le certificazioni on line con timbro digitale.
2.4.1.3 Docenti
Il Docente della Sapienza, in quanto Responsabile di un insegnamento, dispone
delle funzioni per gestire gli appelli d‟esame, la verbalizzazione degli esiti, le
stampe dei verbali o la verbalizzazione digitale, la reportistica e visualizzare le
carriere degli studenti.
Il Docente, in quanto membro di commissioni specifiche, dispone delle funzioni
per la valutazione delle richieste di Part-time, delle domande di Verifica dei
requisiti, etc.
Università La Sapienza di Roma – Capitolato di Gara pag. 7
2.4.1.4 Segreterie didattiche
Anche alcuni uffici delle Facoltà, genericamente raggruppati nel profilo di
segretario didattico, utilizzano Infostud per la gestione degli appelli, del registro
verbale e della visualizzazione delle carriere studenti (esami sostenuti), del part-
time, della verifica dei requisiti.
2.4.1.5 Altri
Esistono altre tipologie di utenti di Infostud che, per esigenze di servizio,
necessitano di funzioni specifiche a supporto delle attività dei loro rispettivi uffici,
come per esempio Programmi internazionali e l‟Ufficio elettorale, oppure utenti
esterni alla Sapienza, autorizzati dall‟Università, come ad esempio l‟ADISU ed
altri ancora.
2.4.2 Stato dell’arte
Si riportano di seguito alcune tabelle sintetiche sull‟utilizzo dell‟applicativo, per
comprendere meglio la dimensione delle attività gestite con Infostud dai vari
uffici ed utenti.
2.4.2.1 Numero Utenti del Sistema
UTENTI SISTEMA
TIPOLOGIA UTENTE NUM. UTENTI
Segreteria Amministrativa 350,00
Altri 20,00
Docente 12.640,00
Segreteria Didattica 59,00
Studente 1.008.821,00
STUDENTI ATTIVI ANNO
ACCADEMICO 2009/2010
Iscritti 111.255
Immatricolati 32.976
TOTALE 144.231
Università La Sapienza di Roma – Capitolato di Gara pag. 8
2.4.2.2 Numero di operazioni effettuate dalle funzioni applicative delle segreterie amministrative nell’anno solare 2010.
0,00
500.000,00
1.000.000,00
1.500.000,00
2.000.000,00
2.500.000,00
GENNAIO
FEBBRAIO
MARZO
APRILE
MAGGIO
GIUGNO
LUGLIO
AGOSTO
SETTE
MBRE
OTTOBRE
NOVEMBRE
DICEM
BRE
Serie1
NUMERO OPERAZIONI
REGISTRATE ANNO 2010
MESE
NUMERO
OPERAZIONI
GENNAIO 456.624,00
FEBBRAIO 1.219.372,00
MARZO 640.086,00
APRILE 252.564,00
MAGGIO 322.464,00
GIUGNO 593.979,00
LUGLIO 701.447,00
AGOSTO 365.720,00
SETTEMBRE 1.036.222,00
OTTOBRE 2.139.400,00
NOVEMBRE 1.763.541,00
DICEMBRE 288.869,00
TOTALE 9.780.288,00
Università La Sapienza di Roma – Capitolato di Gara pag. 9
2.4.2.3 Registrazione Studenti da Web anno 2010.
02.0004.0006.0008.000
10.00012.00014.00016.00018.00020.000
GENNAIO
FEBBRAIO
MARZO
APRILE
MAGGIO
GIUGNO
LUGLIO
AGOSTO
SETTE
MBRE
OTTOBRE
NOVEMBRE
DICEM
BRE
Serie1
2.4.2.4 Numero Corsi e Concorsi attivi per l’anno accademico 2009/2010
REGISTRAZIONE IN
ANAGRAFICA DA WEB
MESI
NUM.
REGISTRAZIONI
GENNAIO 384
FEBBRAIO 273
MARZO 301
APRILE 289
MAGGIO 284
GIUGNO 1.587
LUGLIO 11.186
AGOSTO 18.187
SETTEMBRE 5.654
OTTOBRE 1.366
NOVEMBRE 1.244
DICEMBRE 948
TOTALE 41.703
CONCORSI ATTIVATI
TIPO CONCORSO
NUM
CONCORSI
CORSO ALTA FORMAZIONE 4
DOTTORATO DI RICERCA 168
LAUREA 107
LAUREA DI PRIMO LIVELLO 88
LAUREA MAGISTRALE 115
LAUREA MAGISTRALE A CICLO
UNICO 14
LAUREA MAGISTRALE A PERCORSO
UNITARIO 2
LAUREA SPECIALISTICA 13
MASTER DI PRIMO LIVELLO 92
MASTER DI SECONDO LIVELLO 127
SCUOLA DI SPECIALIZZAZIONE 81
TOTALE 811
CORSI ATTIVI
TIPOLOGIA CORSO
NUM.
CORSI
Lauree DM 270 97
Lauree Specialistiche DM
509 16
Lauree Triennali DM 509 84
Lauree Magistrali 124
UE 3
Dottorati Di Ricerca 181
Master di Primo Livello 92
Master di Secondo Livello 129
Alta Formazione 16
Scuole di Specializzazione 81
TOTALE 823
Università La Sapienza di Roma – Capitolato di Gara pag. 10
2.4.2.5 Numero Bollettini stampati e pagati per l’anno 2010
NUMERO BOLLETTINI
STAMPATI
MESE
NUMERO
BOLLETTINI
GENNAIO 25.284
FEBBRAIO 101.634
MARZO 40.020
APRILE 11.638
MAGGIO 11.712
GIUGNO 8.930
LUGLIO 16.244
AGOSTO 42.093
SETTEMBRE 74.624
OTTOBRE 162.382
NOVEMBRE 178.117
DICEMBRE 17.577
TOTALE 690.255
NUMERO
BOLLETTINI PAGATI
MESE
NUMERO
BOLLETTINI
GENNAIO 9.632
FEBBRAIO 4.522
MARZO 108.215
APRILE 8.796
MAGGIO 5.799
GIUGNO 4.533
LUGLIO 12.921
AGOSTO 36.748
SETTEMBRE 36.720
OTTOBRE 22.976
NOVEMBRE 102.025
DICEMBRE 10.240
TOTALE 363.127
Università La Sapienza di Roma – Capitolato di Gara pag. 11
2.4.2.6 Numero Certificati stampati per l’anno 2010
TIPOLOGIA CERTIFICATO NUM.STAMPE
SEGRETERIA LAUREA 2.121
SEGRETERIA ISCRIZIONE 18.470
SEGRETERIA ESAMI SOSTENUTI 133.926
SEGRETERIA LAUREA CON TESI 2.193
SEGRETERIA LAUREA CON VOTO 9.222
SEGRETERIA LAUREA CON ESAMI 25.766
SEGRETERIA CONFERMA DI LAUREA 725
SEGRETERIA DIPLOMA SUPPLEMENT 243
SEGRETERIA CARRIERA SCOLASTICA 59.915
SEGRETERIA CURRICULUM LAUREANDO 3.504
SEGRETERIA LAUREA CON TIROCINIO 268
SEGRETERIA LAUREA CON TESI /TIROCINIO 15
SEGRETERIA LAUREA CON VOTO /TIROCINIO 67
SEGRETERIA CONFERMA DI LAUREA CON VOTO 2.507
SEGRETERIA CONFERMA DI LAUREA /TIROCINIO 230
SEGRETERIA CARRIERA SCOLASTICA PER CONGEDO 2.303
SEGRETERIA LAUREA PER RISCATTO ANNI ACCADEMICI 3.929
SEGRETERIA CONFERMA DI LAUREA CON VOTO
/TIROCINIO 120
WEB (*) ISCRIZIONE 28.340
WEB (*) ESAMI SOSTENUTI 13.674
WEB (*) LAUREA CON TESI 13.066
WEB (*) LAUREA CON VOTO 16.253
WEB (*) LAUREA CON ESAMI 3.301
WEB (*) LAUREA PER RISCATTO ANNI ACCADEMICI 970
TOTALE 341.128
(*) I certificati su web dal settembre 2010
Università La Sapienza di Roma – Capitolato di Gara pag. 12
2.4.2.7 Numero Laureati e stampa Pergamene anno 2010
TOTALE LAUREATI ANNO 2010
TIPOLOGIA DI LAUREA
NUM.
LAUREATI
CORSO DI DIPLOMA UNIVERSITARIO V.O. 3
CORSO DI LAUREA V.O. 1.393
DIPLOMA V.O. 1
DIPLOMA DI PERFEZIONAMENTO V.O. 5
LAUREA DM270 573
LAUREA DI PRIMO LIVELLO DM509 10.100
LAUREA MAGISTRALE DM270 714
LAUREA MAGISTRALE A CICLO UNICO DM270 3
LAUREA MAGISTRALE A PERCORSO UNITARIO DM270 425
LAUREA SPECIALISTICA DM509 5.268
LAUREA SPECIALISTICA A CICLO UNICO DM509 1.298
SCUOLA 45
SCUOLA DI SPECIALIZZAZIONE 718
TOTALE 20.546
TOTALE PERGAMENE STAMPATE(*) 23.643
(*) Le pergamene stampate possono risultare in numero maggiore degli studenti laureati in
quanto, nel periodo di osservazione, le stampe sono relative anche agli studenti laureati
prima del 1 gennaio 2010.
2.4.2.8 Verbalizzazione degli esami
Verbalizzazione AA 2009/2010
CORSI DI STUDIO 849
VERBALI 59.493
INSEGNAMENTI 16.586
DOCENTI 6.204
PRENOTATI 809.069
VERBALIZZATI 792.169
AGGIUNTI 28.056
VALIDATI 617.484
2.4.2.9 Numero Studenti regolari e non regolari anno accademico 2010
POSIZIONE
AMMINISTRATIVA STUDENTI
REGOLARE 128.066
NON REGOLARE 20.206
TOTALE 148.272
Università La Sapienza di Roma – Capitolato di Gara pag. 13
2.4.3 INFRASTRUTTURA IT
L‟infrastruttura tecnologica di Infostud è composta dai seguenti ambienti:
Ambiente di esercizio o produzione
Ambiente di test correttivo
Ambiente di test evolutivo
Ambienti di sviluppo
L‟ambiente d‟esercizio è separato per tipologia utente ed opera su intranet e/o
internet. Gli ambienti di test e sviluppo sono sulla intranet.
2.4.3.1 Software applicativo:
Il sistema Infostud può essere diviso nei seguenti componenti applicativi:
componente di Front-end web
costituito da un‟applicazione web-based, sviluppata in java utilizzando la
Java Virtual Machine versione 1.4.2_14, l‟Enterprise JavaBeans versione
1.0 ed il framework Struts 1.1 eseguita su Oracle Application Server
componente Back-end dati
costituito dalla base dati e da un insieme di procedure oracle PL/SQL
eseguite su Oracle Enterprise Server 11g.
componente per i servizi web
costituito da un insieme di servizi web sviluppati in java utilizzando la
JVM 1.5 ed eseguiti su Apache Tomcat 6.0.
altri componenti
costituiti da librerie ed eseguibili java e/o package PL/SQL sviluppati ad
hoc per consentire la collaborazione applicativa e lo scambio di dati con
sistemi esterni.
In totale in produzione esistono 225 moduli java per la gestione di tutte le
funzionalità di Infostud e 304 stored procedure. Di seguito le principali librerie
esterne utilizzate:
iText 5.0 e jasperReport 1.0 per la generazione di documenti
Apache axis 1.2 e successive per le chiamate web services
log4j 1.2.8 per la gestione della log
BouncyCastle jdk14-145 per la crittografia
Università La Sapienza di Roma – Capitolato di Gara pag. 14
prototype 1.7 per quanto riguarda javascript e ajax
2.4.3.2 Ambiente di esercizio
L‟architettura del progetto Infostud è basata su un sistema multi-livello (tier) dove
insistono gli applicativi per le Segreterie e per gli Studenti.
Figura 3 - Infrastruttura Infostud
A questa architettura vanno aggiunti alcuni componenti satellitari utilizzati
principalmente nella collaborazione applicativa come p.es. i web services Infostud
(vedi Figura 2).
2.4.3.2.1 Front-end Web: Application Server
Il front-end web è realizzato tramite application server raggruppati in due Web
Farm, una per l‟uso degli studenti e dei docenti e l‟altra ad uso delle segreterie, le
web farm forniscono servizi differenti.
Università La Sapienza di Roma – Capitolato di Gara pag. 15
Gli Application server sono ospitati su HP Blade system Enclosure C7000 e sono
connessi con il database Oracle RAC attraverso una connessione Ethernet ad 1
Gb.
Ogni Application Server di Segreteria ha le seguenti caratteristiche:
Server BL465G5 con 2 CPU AMD Opteron 3Ghz, 16Gb di Ram, raid
mirror di 2 dischi da 146Gb, scheda in fibra ottica, 4 NIC ethernet
Sistema Operativo: Red Hat Enterprise Linux 4
Middleware: Oracle Application Server 10.1.2.3.0 in combinazione con la
web cache, il server web apache e il relativo container delle pagine java
OC4J.
Ogni Application Server della Web Farm degli studenti ha le seguenti
caratteristiche:
Server BL465G5 con 2 CPU Intel Xeon 2,4Ghz, 10Gb di Ram, raid mirror
di 2 dischi da 146Gb, scheda in fibra ottica, 4 NIC ethernet
Sistema Operativo: Red Hat Enterprise Linux 4
Middleware: Oracle Application Server 10.1.2.3.0 in combinazione con la
web cache, il server web apache e il relativo container delle pagine java
OC4J.
Inoltre, per quanto riguarda la connettività, i Blade Systems sono predisposti
ognuno con 8 switch cisco catalyst 3020 su cui arrivano gli 8 trunk dallo switch di
frontiera.
Alle componenti di base sono necessari i seguenti servizi di supporto:
LDAP server per l‟utilizzo della posta della posta elettronica studenti.
Load Balancer per il bilanciamento del carico utente su più Web Server.
2.4.3.2.2 Back-end: Oracle Database Rac
La base dati di Infostud è ospitata su due sistemi in cluster con le seguenti
caratteristiche:
Server BL680G5 ciascuno con 2 CPU AMD Opteron 3Ghz, 32Gb di Ram, raid
mirror di 2 dischi da 300Gb, scheda in fibra ottica, 4 NIC ethernet
Sistema Operativo: Red Hat Enterprise Linux 5
Database: Oracle Real Application Cluster in combinazione con Oracle 11g
Il database server utilizza un file system su SAN (Storage Area Network) di HP
mod. StorageWorks EVA4000 di circa 12Tb distribuiti su 56 dischi da 300 Gb
15000rpm in fibra di cui 2Tb in produzione per la sola istanza del database.
Università La Sapienza di Roma – Capitolato di Gara pag. 16
L‟infrastruttura è comprensiva per la gestione dei virtual array (vraid0, vraid1,
vraid5) della suite HP Command View. Le soluzioni HP StorageWorks EVA
permettono di gestire lo storage mediante snapshot di base e creare mirror in
remoto tramite un‟interfaccia utente ed una infrastruttura CLI (Common
Language Infrastructure).
2.4.3.2.3 Web Services
I servizi web utilizzati nella collaborazione applicativa sono realizzati in Java 1.5
utilizzando le librerie Apache Axis e sono ospitati su web servers raggruppati in
una web farm. Ogni web server ha le seguenti caratteristiche:
Sistema Operativo: Linux Debian 5
Middleware: Apache Web Sever 2.2.x e Apache Tomcat 6.0.
2.4.3.2.4 Backup
Per il backup dei sistemi in esercizio viene utilizzata la libreria HP StorageWorks
MSL5026 Library con 24 slot per tape modello DLT 40/80 Gb
Sono previsti le seguenti modifiche all‟attuale configurazione:
HP StorageWorks MSL6000 Library Ultrium LTO-4 con 32 slot per tape
da 800GB.
2.4.3.3 Ambiente Test
Gli ambienti di test sia correttivo che evolutivo sono costituiti da più sistemi
ospitati su macchine reali o virtuali che rispecchiano le caratteristiche
dell‟ambiente di esercizio con le seguenti differenze:
gli application server non costituiscono una web farm e quindi non è
presente un bilanciatore
il DB non è configurato in cluster
I sistemi reali o virtuali che ospitano sia gli application server che i sistemi DB
hanno caratteristiche inferiori in termini prestazionali rispetto all‟ambiente di
esercizio.
2.4.3.4 Ambiente di sviluppo
L‟ambiente di sviluppo del sistema infostud è disponibile ad ogni singolo
sviluppatore sulla propria postazione di lavoro, gli strumenti maggiormente
Università La Sapienza di Roma – Capitolato di Gara pag. 17
utilizzati sono: JDeveloper 10.1.2, Eclipse Java EE IDE, WinCVS, PLSQL
Developer, SQL Developer
Tutti gli ambienti di sviluppo condividono la stessa istanza del DB disponibile su
un server remoto dedicato.
Università La Sapienza di Roma – Capitolato di Gara pag. 18
2.5 ORGANIZZAZIONE UNIVERSITA’ LA SAPIENZA
La Sapienza si avvale per lo svolgimento delle sue attività, oltre che dei
Dipartimenti e delle Facoltà e, ove costituiti, dei Centri, della Direzione generale e
dell‟Amministrazione.
La Direzione generale è articolata in aree organizzative, dotate di autonomia
attuativa ed organizzativa.
Infosapienza è un Centro di spesa ad ordinamento speciale, di programmazione e
di sviluppo tecnologico, finalizzato al supporto della Information Communication
Technology della “Sapienza”. Il Centro di spesa è diretto, per gli aspetti
d‟indirizzo e programmazione, da un delegato del Rettore, coadiuvato a titolo
consultivo da un Comitato, ed ha un dirigente responsabile tecnico-
amministrativo, nominato dal Direttore generale.
La gestione del sistema Infostud, è a carico del settore Settore informatico per le
carriere didattiche e amministrative degli studenti del Centro Infosapienza e
prevede la manutenzione correttiva ed adeguativa del software, lo sviluppo, la
manutenzione dell‟infrastruttura tecnologica, il supporto agli utenti, la gestione
applicativa e base dati.
Il personale della Sapienza è integrato da quello di consulenti e collaboratori
esterni e da studenti borsisti, che svolgono la propria attività presso l‟Università e
sotto il coordinamento del Responsabile del Settore.
2.5.1 La manutenzione dell’infrastruttura tecnologica
Le attività svolte a questo scopo dalle risorse assegnate, devono assicurare il
corretto funzionamento dell‟intera architettura di sistema, così come descritta
precedentemente, per i diversi ambienti di Esercizio, Test e Sviluppo, includendo,
oltre che la gestione dei server, anche del middleware Application e di quello Data
Base. L‟attività riguarda anche il tuning e le performance dell‟intera infrastruttura
ed il relativo aggiornamento, oltre che la sicurezza ed il backup/restore dei dati.
E‟ gestito dalle stesse risorse il CVS, (Concurrent Versioning System) e l‟attività
di deploy. Infine, partecipano, al controllo ed interpretazione dei log applicativi
insieme agli analisti.
2.5.2 Manutenzione del software
Ha in carico tutte le attività di sviluppo e correzione dell‟applicativo Infostud.
L‟attività di manutenzione correttiva riguarda sia la correzione degli errori
applicativi, sia dei dati. Quest‟ultima è effettuata anche dall‟ help desk.
Università La Sapienza di Roma – Capitolato di Gara pag. 19
L‟attività di sviluppo comprende la manutenzione adeguativa del sistema e quella
evolutiva.
Sono ricomprese nelle attività del gruppo tutte le fasi di analisi, progettazione,
programmazione e testing.
2.5.3 Help Desk e supporto utenti
L‟attività di supporto agli utenti si distingue in help desk di 1° e 2° livello.
E‟ identificata come attività di primo livello, la segnalazione dell‟anomalia che è
risolvibile utilizzando correttamente le funzioni applicative e non rappresenta un
reale malfunzionamento.
Il servizio di Help Desk di secondo livello, invece, gestisce problematiche non
risolvibili con le funzioni applicative e presuppone un intervento tecnico ad hoc.
Il gruppo acquisisce anche le eventuali anomalie funzionali, le trasmette al
servizio di manutenzione e ne verifica la correzione; infine, monitora il corretto
funzionamento dell‟applicativo.
Inoltre, si occupa delle attività di verbalizzazione via web degli esami, supporta i
docenti, le segreterie amministrative e didattiche ed i vari uffici dell‟Ateneo per
interventi d‟aiuto di 1 e 2 livello, gestisce la codifica e le problematiche relative
alle cooperazioni applicative.
Degli studenti non regolari, circa il 25% necessita di un intervento tecnico
puntuale a sanatoria direttamente sulla base dati.
Nel periodo 5 settembre-3ottobre sono state effettuati circa 1200 interventi di
assistenza di 1° e 2° livello.
Data la variabilità della tipologia di intervento, il tempo medio di risoluzione non
aiuta ad inquadrare al meglio l‟attività, in quanto sono presenti interventi di pochi
minuti e altri di ore.
Il servizio di help desk è effettuato dalle 9 alle 17:30 con intervallo per il pranzo
dalle 13:00 alle 14:00.
2.5.4 Gestione applicativa e base dati
Si occupa della gestione giornaliera dei flussi bancari e del recupero degli scarti.
Gestisce i flussi dati per la gestione di tutti i concorsi della Sapienza per l‟accesso
ai corsi di 1° e 2° livello, master, specializzazione, dottorati (numero chiuso,
orientamento, prove ingresso verifica delle conoscenze e domande verifica
requisiti), predispone report ed elaborazioni dei dati.
Codifica gli insegnamenti, gestisce la programmazione degli appelli d‟esame.
Università La Sapienza di Roma – Capitolato di Gara pag. 20
Predispone il sistema per l‟avvio di ogni anno accademico (caricamento
dell‟offerta formativa, regole contabili, date istituzionali etc.) secondo le regole
previste dal manifesto degli studi.
Aggiorna il data base delle informazioni “fuori sistema” (ad esempio vincitori
borse ADISU).
Predispone il sistema per gli invii massivi (bollettini di 1 e 2 rata delle tasse,
badge, etc)
Università La Sapienza di Roma – Capitolato di Gara pag. 21
3 Descrizione della fornitura
L‟oggetto della fornitura è rappresentato dall‟insieme dei servizi e delle attività
volti ad assicurare e garantire la piena operatività e le future evoluzioni del
Sistema Informativo INFOSTUD (paragrafo 2.4), incluso le componenti per le
collaborazioni applicative e le altre componenti aggiuntive.
Oggetto della fornitura sono i servizi di:
manutenzione correttiva
manutenzione adeguativa
manutenzione evolutiva
assistenza utenti e help desk 2° livello
servizi di gestione applicativi e Basi Dati
Si precisa che, sia per la manutenzione correttiva che per quella evolutiva, negli
ultimi 2 mesi di validità del contratto il Fornitore dovrà fornire ai referenti di
Infosapienza o a terzi da essa designati, il trasferimento del know-how sulle
attività condotte, al fine di rendere l‟eventuale prosecuzione delle attività quanto
più efficace possibile secondo le modalità indicate nel Paragrafo 6.1.2
Nel seguito si definiscono in dettaglio le attività sopra elencate. I casi concreti
riportati nel presente capitolo sono da intendersi solo a titolo d‟esempio e non
come esaustivi della realtà in Sapienza.
3.1 Servizi di Manutenzione correttiva
Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e
degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti
delle procedure e dei programmi in esercizio.
Il servizio di manutenzione correttiva è normalmente attivato attraverso una
segnalazione di impedimenti all‟esecuzione dell‟applicazione/funzione o dal
riscontro di differenze fra l‟effettivo funzionamento del software applicativo e
quello atteso, come previsto dalla relativa documentazione o comunque
determinato dai controlli che vengono svolti durante l‟attività dell‟utente (nel
seguito chiamati anche malfunzioni o malfunzionamenti).
Il servizio di manutenzione correttiva è teso alla risoluzione dei difetti presenti nel
codice sorgente, o nelle specifiche di formato o di base dati, non rilevati a suo
tempo durante il ciclo di sviluppo o la verifica di conformità.
Dal momento in cui la richiesta è comunicata al Fornitore decorrono i tempi
relativi ai livelli di servizio definiti nel seguito del Capitolato.
I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel
software applicativo, ma ad errori tecnici, operativi o d‟integrazione con altri
Università La Sapienza di Roma – Capitolato di Gara pag. 22
sistemi, possono comportare, da parte del servizio di manutenzione correttiva, il
supporto all‟attività diagnostica sulla causa del malfunzionamento, a fronte della
segnalazione pervenuta, e la risoluzione in termini di assistenza agli utenti.
Sono, altresì, parte integrante del servizio di manutenzione correttiva le seguenti
attività:
1. partecipazione, durante il periodo di verifica di congruità, alle attività di
presa in carico per la gestione dei prodotti sviluppati e da rilasciare in
esercizio, al fine di acquisire il know-how necessario al corretto
svolgimento del servizio di manutenzione.
2. affiancamento di inizio e fine fornitura per il trasferimento del know-how
relativo al funzionamento del sistema informatico.
Per il servizio di manutenzione correttiva si richiede che il fornitore produca
mensilmente il Riepilogo Mensile degli Interventi. Si precisa che Infosapienza
potrà anche richiedere al fornitore altri report riepilogativi quali a titolo
esemplificativo e non esaustivo la Scheda di intervento di Manutenzione
Correttiva che contiene la data di attivazione dell‟intervento, l‟anomalia, la
categoria, la data chiusura richiesta per l‟intervento, la causale dell‟anomalia, il
nome della funzione modificata, durata dell‟intervento, la data chiusura effettiva
dell‟intervento ed altre informazioni da concordare.
3.1.1 Dimensionamento
Sulla base delle conoscenze attuali, dell‟esperienza degli anni precedenti, delle
esigenze utente e della relativa evoluzione pianificata, ad oggi, si è stimato in 380
GP l‟impegno necessario al servizio di manutenzione correttiva. Al mutare delle
esigenze, e quindi delle risorse impegnate in quantità e qualità, il piano d‟impiego,
potrà essere rivisto ed aggiornato, nel limite del massimale di GP proposto in
offerta.
Segue la tabella che segue riporta la ripartizione negli anni dell‟impegno in GP
previsto per la manutenzione correttiva
Impegno in GP
Servizi di manutenzione correttiva Totale I anno II anno
380 190 190
3.1.2 Composizione dei Gruppi di Lavoro
Per i servizi di manutenzione correttiva è richiesto al Fornitore l‟impegno di
almeno le seguenti figure professionali:
Responsabile del servizio
Analista Funzionale
Università La Sapienza di Roma – Capitolato di Gara pag. 23
Analista Programmatore Java
Analista Programmatore Pl/Sql
Il piano di impiego stimato è riportato nella tabella seguente:
Figura Professionale % Utilizzo
Responsabile del servizio 20
Analista Funzionale 40
Analista Programmatore Java 20
Analista Programmatore Pl/Sql 20
3.2 Servizi di Manutenzione Adeguativa
La manutenzione adeguativa comprende l‟insieme delle attività volte ad assicurare
la costante aderenza delle procedure e dei programmi alla evoluzione
dell‟ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti
(organizzativi, normativi, d‟ambiente) ed include:
adeguamenti dovuti a seguito di cambiamenti di condizioni al contorno (ad
esempio per variazioni al numero utenti, per migliorie di performance, per
aumento delle dimensioni delle basi dati, ecc.);
adeguamenti dovuti a seguito di cambiamenti organizzativi e normativi (ad
esempio riordino delle strutture interne all‟università,ecc.);
adeguamenti necessari per innalzamento di versioni del software di base;
adeguamenti intesi all‟introduzione di nuovi prodotti o modalità di
gestione del sistema;
migrazioni di piattaforma;
modifiche, anche massive, non a carattere funzionale, alle applicazioni.
3.2.1 Dimensionamento
Sulla base delle conoscenze attuali, dell‟esperienza degli anni precedenti, delle
esigenze utente e della relativa evoluzione pianificata, ad oggi, si è stimato in 400
GP l‟impegno necessario al servizio di manutenzione adeguativa. Al mutare delle
esigenze, e quindi delle risorse impegnate in quantità e qualità, il piano d‟impiego,
potrà essere rivisto ed aggiornato, nel limite del massimale di GP proposto in
offerta.
Segue la tabella che segue riporta la ripartizione negli anni dell‟impegno in GP
previsto per la manutenzione adeguativa.
Università La Sapienza di Roma – Capitolato di Gara pag. 24
Impegno in GP
Servizi di manutenzione adeguativa Totale I anno II anno
400 200 200
3.2.2 Composizione dei Gruppi di Lavoro
Per i servizi di manutenzione adeguativa è richiesto al Fornitore l‟impegno di
almeno le seguenti figure professionali:
Responsabile del servizio
Analista Funzionale
Analista Programmatore Java
Analista Programmatore Pl/Sql
Il piano di impiego stimato è riportato nella tabella seguente:
Figura Professionale % Utilizzo
Responsabile del servizio 20
Analista Funzionale 40
Analista Programmatore Java 20
Analista Programmatore Pl/Sql 20
3.3 Servizi di Manutenzione Evolutiva
3.3.1 Descrizione Requisiti
I servizi di manutenzione evolutiva si articolano in :
Manutenzione Evolutiva sul sistema Infostud
Integrazione di Infostud con U-GOV
3.3.1.1 Manutenzione evolutiva sul sistema Infostud
La manutenzione evolutiva è finalizzata alla realizzazione di ulteriori funzionalità
volte a soddisfare le esigenze dell‟utente. Tale realizzazione riguarda
l‟inserimento di nuove funzionalità informatiche non presenti nell‟attuale sistema
Infostud e/o la modifica delle funzioni previste dalla attuale architettura.
L‟attività di sviluppo è suddivisa per obiettivi, la cui esecuzione è in fasi, secondo
un ciclo di sviluppo dipendente dalle dimensioni, dalla criticità e dalla tipologia di
applicazione.
Università La Sapienza di Roma – Capitolato di Gara pag. 25
Le attività descritte non si devono ritenere esaustive della realizzazione, in quanto
le attività oggetto del servizio saranno definite nell‟apposita fase di “definizione”
prevista nelle modalità di svolgimento del servizio.
La manutenzione evolutiva comprende altresì le attività di parametrizzazione e
personalizzazione della piattaforma software. La parametrizzazione consiste
nell‟aggiornamento e controllo della configurazione del prodotto software in base
ai requisiti dell‟utente, la personalizzazione consiste nella creazione ed
integrazione nel sistema di funzionalità che offrono valore aggiunto. Tali attività
devono comunque fornire un sistema che garantisca la piena soddisfazione dei
requisiti richiesti dall‟utente.
Costituisce parte integrante dell„attività di manutenzione evolutiva la garanzia
sulla fornitura, per tutte le componenti realizzate/personalizzate, fino a 6 (sei)
mesi oltre la scadenza del Contratto.
3.3.1.2 Integrazione Infostud in U-GOV
L‟Ateneo ha individuato U-GOV come l‟architettura in grado di facilitare
l‟interscambio delle informazioni e l‟interoperabilità delle applicazioni di Ateneo.
Allo stesso tempo, questa architettura dovrebbe consentire l‟evoluzione nel tempo
del sistema informatico facilitando l‟implementazione di nuove applicazioni e
servizi, senza il proliferare di tecnologie eterogenee. Il concetto di “integrazione”,
inoltre, non è limitato alle sole applicazioni interne all‟Ateneo, ma dovrà
estendersi coinvolgendo i processi nazionali tipici del mondo universitario, verso,
ad esempio, l‟anagrafe nazionale degli studenti, l‟anagrafe nazionale dei prodotti
della ricerca e la banca dati nazionale dell‟offerta formativa.
Relativamente all‟area Didattica e Studenti il sistema U-GOV prevede due
applicazioni che in Sapienza sono realizzate tramite il sistema SIAD: proprio per
questo motivo, una delle attività principali indicate nei servizi evolutivi consiste
nel realizzare l‟integrazione del sistema della Didattica e degli Studenti (Infostud)
nell‟ambito della piattaforma U-GOV di CINECA che, appunto, è stata scelta
dall‟Ateneo come sistema di riferimento per la gestione dei processi
amministrativi, come strumento di analisi e controllo di gestione dell‟Ateneo e
come piattaforma di erogazione di contenuti e servizi (area pubblica e privata del
Portale).
Nell‟appendice “U-GOV Architettura, tecnologia e applicazioni” sono riportati
maggiori dettagli sulla componente U-GOV.
In tale accezione è necessario che si attivi un processo di integrazione delle
applicazioni attualmente operanti verso l‟architettura applicativa U-GOV in modo
che le informazioni siano condivise dai diversi sistemi. Tra questi il principale è
appunto Infostud.
Poiché l‟integrazione di sistemi complessi richiede tempi ed impegni significativi
essa si dovrà realizzare contemporaneamente alle normali attività di gestione dei
Università La Sapienza di Roma – Capitolato di Gara pag. 26
sistemi intendendo con questo la manutenzione correttiva, normativa ed evolutiva
degli stessi.
L‟integrazione tra Infostud (o più in generale SIAD) e la Piattaforma U-GOV
deve prevedere dei meccanismi di condivisione delle informazioni, o più in
generale di collaborazione applicativa, che possano essere realizzati in modo
incrementale.
A titolo di esempio riportiamo alcuni degli ambiti dei quali la condivisione delle
informazioni e la collaborazione applicativa dovrannò operare:
gestione centralizzata ed univoca delle informazioni, in particolare tutte le
informazioni anagrafiche che hanno caratteristica di essere condivise da
più applicazioni e quelle utili a descrivere l‟Amministrazione in termini
organizzativi e di struttura;
integrazione nel DB di U-GOV dei dati degli Studenti.
estrazioni verso l‟ANS (anagrafe nazionale studenti) che, essendo secondo
modalità e tracciati standard, hanno logiche ed evoluzioni dettate da
adeguamenti normativi che sarebbero gestibili centralmente dal sistema U-
GOV.
Di seguito si riportano a titolo di esempio ed in modo non esaustivo alcuni
elementi che vanno condivisi tra le applicazioni:
Struttura Organizzativa dell‟Ateneo
Struttura Didattica
Offerta Didattica
Piani di Studio/Regole di Scelta
Logistica e Coperture
Anagrafica delle Persone e più in generale tutte le informazioni anagrafiche
che hanno pluralità di interesse
Carriere Studenti
Matricole e Iscrizioni
Piani e Libretti degli studenti
Esami
Posizione debitoria/creditoria dello studente
Università La Sapienza di Roma – Capitolato di Gara pag. 27
Emissione ed incasso delle Tasse
Autocertificazioni
Dati contabili
3.3.2 Dimensionamento
Sulla base delle conoscenze attuali, dell‟esperienza degli anni precedenti, delle
esigenze utente e della relativa evoluzione pianificata, ad oggi, si è stimato in
1130 GP l‟impegno necessario al servizio di manutenzione evolutiva. Al mutare
delle esigenze, e quindi delle risorse impegnate in quantità e qualità, il piano
d‟impiego, potrà essere rivisto ed aggiornato, nel limite del massimale di GP
proposto in offerta.
Segue la tabella che segue riporta la ripartizione negli anni dell‟impegno in GP
previsto per la manutenzione evolutiva
Impegno in GP
Totale I anno II anno
Servizi di manutenzione evolutiva Infostud 630 315 315
Servizi di Integrazione Infostud-UGOV 500 250 250
3.3.3 Composizione dei Gruppi di Lavoro
Per i servizi di manutenzione evolutiva è richiesto al Fornitore l‟impegno di
almeno le seguenti figure professionali:
Responsabile del servizio
Analista Funzionale
Analista Programmatore Java
Analista Programmatore Pl/Sql
Il piano di impiego stimato è riportato nella tabella seguente:
Figura Professionale % Utilizzo
Responsabile del servizio 20
Analista Funzionale 40
Analista Programmatore Java 20
Analista Programmatore Pl/Sql 20
Università La Sapienza di Roma – Capitolato di Gara pag. 28
3.4 Servizi di Assistenza utenti e help desk
L‟assistenza operativa e funzionale agli utenti dovrà essere erogata attraverso un
servizio di help desk di primo e secondo livello.
Il presente servizio riguarda l‟assistenza agli utenti, sia per l‟utilizzo “operativo”
delle funzionalità applicative, sia per l‟uso appropriato delle funzioni stesse,
finalizzato alla risoluzione di problemi amministrativi nell‟ottica del superamento
di eventuali limitazioni derivati da carenze formative e/o dalle naturali rotazioni di
organico tra gli Uffici.
Questo servizio deve almeno prevedere l‟assistenza operativa agli utenti
relativamente all‟uso appropriato delle funzionalità applicative, secondo le
modalità previste dai manuali d‟uso e il supporto alla gestione dei processi
amministrativi.
Le attività di assistenza si inquadrano in un modello organizzativo , come
riportato nella Tabella 1 ,che vede il Fornitore presidiare le aree applicative
interagendo con il gruppo di lavoro costituito da Infosapienza.
Segreterie
Amministrative
Verbalizzazione
Esami Assistenza Utenti
Infosapienza Help Desk 1° e 2°
Livello
Help Desk 1° Livello Help Desk 1° e 2°
Livello
Fornitore Help Desk 1 e 2°
Livello
Help Desk 2° Livello Help Desk 1° e 2°
Livello
Tabella 1
Le attività di presidio delle aree applicative sono svolte al fine di assicurare un
alto livello di supporto, sia direttamente all‟utente, sia con attività proprie
dell‟help desk di secondo livello, sia nella gestione del progetto nella sua
globalità. La struttura predisposta dovrà fornire il seguente supporto:
Help desk di primo livello: supporto erogato a fronte di richieste pervenute
direttamente dagli utenti dei vari uffici;
Help desk di secondo livello: supporto erogato a fronte di richieste filtrate
da personale tecnico di Infosapienza.
Il servizio di supporto si esplicita anche attraverso le attività erogate dal Fornitore
a fronte di richieste di supporto pervenute attraverso il personale tecnico di
Infosapienza per la gestione di problemi applicativi quali:
l‟intercettazione di eventuali malfunzionamenti alla fonte, tramite una
prima attività di diagnosi e l‟attivazione dei gruppi di manutenzione
correttiva attraverso le schede di segnalazione.
Università La Sapienza di Roma – Capitolato di Gara pag. 29
la realizzazione di prodotti e servizi “ad hoc”, per soddisfare particolari e
puntuali esigenze non risolvibili con le funzionalità standard del Sistema
Informativo.
il supporto alla pianificazione funzionale del servizio, in accordo con gli
organi tecnici di Infosapienza, che comporti l‟attivazione del servizio di
manutenzione adeguativa, migliorativa ed evolutiva.
supporto all‟avviamento in esercizio.
assistenza tecnico/funzionale agli utenti durante il periodo iniziale di
esercizio delle applicazioni.
assistenza operativa agli utenti, per l‟uso appropriato delle funzioni
secondo le modalità previste nei manuali d‟uso.
assistenza agli utenti su tematiche funzionali/amministrative per la
risoluzione di problemi d‟interpretazione delle norme d‟uso.
supporto specialistico all‟assistenza per le applicazioni in esercizio.
3.4.1 Dimensionamento
Sulla base delle conoscenze attuali, dell‟esperienza degli anni precedenti, delle
esigenze utente e della relativa evoluzione pianificata, ad oggi, si è stimato in 400
GP l‟impegno necessario al servizio di assistenza utenti e help desk. Al mutare
delle esigenze, e quindi delle risorse impegnate in quantità e qualità, il piano
d‟impiego, potrà essere rivisto ed aggiornato, nel limite del massimale di GP
proposto in offerta.
Segue la tabella che segue riporta la ripartizione negli anni dell‟impegno in GP
previsto per l‟assistenza utenti e l‟help desk
Impegno in GP
Servizi di assistenza utenti ed help desk Totale I anno II anno
400 200 200
3.4.2 Composizione dei Gruppi di Lavoro
Per i servizi di manutenzione evolutiva è richiesto al Fornitore l‟impegno di
almeno le seguenti figure professionali:
Responsabile del servizio
Analista Funzionale
Università La Sapienza di Roma – Capitolato di Gara pag. 30
Analista Programmatore Java
Analista Programmatore Pl/Sql
Il piano di impiego stimato è riportato nella tabella seguente:
Figura Professionale % Utilizzo
Responsabile del servizio 20
Analista Funzionale 40
Analista Programmatore Java 5
Analista Programmatore Pl/Sql 35
3.4.3 Orari assistenza utenti e help desk
Il servizio di help desk dovrà essere attivato nei seguenti orari :
Segreterie Amministrative
Lunedi – Mercoledi – Venerdì dalle ore 8.30 alle 12.30
Martedì – Giovedi dalle ore 14.30 alle 16.30
Verbalizzazione
Lunedì – Venerdì dalle ore 9.00 alle 16.00
Assistenza Utenti
Lunedì – Venerdì dalle ore 9.00 alle 18.00
3.5 Servizi di gestione applicativi e Basi Dati
3.5.1 Descrizione requisiti
I servizi di gestione sono svolti da parte di risorse professionali del Fornitore, e
sono orientati all‟esercizio del sistema ed all‟assistenza degli utenti. Essi si
articolano in interventi diversi riconducibili alle tipologie di seguito riportate.
Università La Sapienza di Roma – Capitolato di Gara pag. 31
3.5.1.1 Piccoli Interventi
Sono riconducibili alle modifiche urgenti alle funzioni, da realizzarsi con risorse e
tempi contenuti, quali ad esempio, la modifica di una transazione o di un report
per una diversa prospettazione dei dati. Tali modifiche non comportano alcun
impatto significativo sull‟architettura generale delle applicazioni, sui processi o
sull‟organizzazione del lavoro degli utenti finali.
3.5.1.2 Prodotti/servizio
La categoria prodotti/servizio prevede la realizzazione di prodotti informatici o lo
svolgimento di servizi “ad hoc”, per soddisfare particolari e puntuali esigenze
dell‟utente, non risolvibili con le funzionalità disponibili nel sistema informativo,
e che di norma non entrano a far parte stabile del parco applicativo. Rientrano in
tale ambito anche:
gli interventi puntuali di correzione di una banca dati
la creazione di prospetti informativi usa-e-getta;
esecuzione di sperimentazioni (che non producano software applicativo);
sviluppo di prototipi, di tipo “usa e getta” per esigenze non direttamente
collegabili all‟attività amministrativa (ad esempio per partecipazione a
convegni, seminari, eventi pubblici)
L‟elenco non si può considerare esaustivo ed immutabile, ma potrà subire delle
revisioni nel periodo di validità contrattuale per comprendere attività affini e
comunque orientate a supportare lo sviluppo, la manutenzione e la gestione di
INFOSTUD.
3.5.1.3 Back-end
Per back-end si intendono le seguenti attività:
1. presa in carico di nuove funzionalità in esercizio:
schedulazione e pianificazione del rilascio in esercizio di nuove
funzionalità;
verifica e validazione dei prodotti per la gestione: procedure,
parametri e tabelle, manuale utente, manuale di gestione, definizioni
relative ai dati;
validazione tecnica e controllo dei risultati delle elaborazioni, al fine
di assicurare l‟integrità e la correttezza dei dati presenti sulla base
informativa, del contenuto dei flussi informativi provenienti o
Università La Sapienza di Roma – Capitolato di Gara pag. 32
destinati ad organismi esterni, dei dati esposti negli elaborati del
sistema.
2. pianificazione funzionale del servizio (e ripianificazione, per eccezione) in
accordo con gli organi tecnici ed amministrativi della Sapienza:
controllo e fasatura dell‟introduzione di nuove versioni di software di
base (anche in via estemporanea e/o transitoria) nell‟ambiente gestito;
pianificazione ed esecuzione di elaborazioni di prova, con relativa
ripresa di dati reali, a scopo di manutenzione preventiva, per
anticipare l‟esito dell‟elaborazione di procedure critiche per la
Sapienza;
modifiche di parametri di esecuzione o di tabelle di riferimento o
decodifica.
3. monitoraggio sull‟utilizzo del sistema:
definizione ed elaborazione di statistiche relative all‟utilizzo, alla
verifica dei dati, ecc. riguardanti qualsiasi processo implementato sul
sistema;
supporto alla verifica periodica dei livelli prestazionali del sistema in
particolare a fronte di nuovi rilasci o dell‟innalzamento del numero di
utenti abilitati
Rientra nel servizio di gestione applicativi e basi dati l‟attività di trasferimento di
know how secondo le modalità descritte nel paragrafo 6.1.2
Nell‟eventualità che la Sapienza costituisse una struttura con il compito di
prendere in carico le attività, il Fornitore dovrà garantire il trasferimento di tutte le
conoscenze necessarie e delle modalità operative necessarie per lo svolgimento
dell‟attività.
L‟elencazione delle attività suddette non si può considerare esaustivo ed
immutabile, ma potrà subire delle revisioni nel periodo di validità contrattuale per
comprendere attività affini e comunque orientate a supportare la manutenzione e
la gestione di INFOSTUD.
3.5.2 Dimensionamento
Sulla base delle conoscenze attuali, dell‟esperienza degli anni precedenti, delle
esigenze utente e della relativa evoluzione pianificata, ad oggi, si è stimato in 340
GP l‟impegno necessario al servizio di gestione applicativi e basi dati. Al mutare
delle esigenze, e quindi delle risorse impegnate in quantità e qualità, il piano
d‟impiego, potrà essere rivisto ed aggiornato, nel limite del massimale di GP
proposto in offerta.
Segue la tabella che segue riporta la ripartizione negli anni dell‟impegno in GP
previsto per la gestione applicativi e della basi dati
Università La Sapienza di Roma – Capitolato di Gara pag. 33
Impegno in GP
Servizi di Gestione applicativi e Basi Dati Totale I anno II anno
340 150 190
3.5.3 Composizione dei Gruppi di Lavoro
Per i servizi di manutenzione evolutiva è richiesto al Fornitore l‟impegno di
almeno le seguenti figure professionali:
Responsabile del servizio
Analista Funzionale
Analista Programmatore Java
Analista Programmatore Pl/Sql
Il piano di impiego stimato è riportato nella tabella seguente:
Figura Professionale % Utilizzo
Responsabile del servizio 20
Analista Funzionale 40
Analista Programmatore Java 5
Analista Programmatore Pl/Sql 35
Università La Sapienza di Roma – Capitolato di Gara pag. 34
4 Modalità di esecuzione
4.1 Modalità di esecuzione dei servizi e delle attività
Al fine di descrivere le modalità di esecuzione dei servizi e delle attività di
fornitura, viene qui di seguito fornita una matrice di associazione relativamente
alle differenti modalità di esecuzione e cicli di sviluppo da adottare.
Servizio Metrica Modalità Ciclo di
Sviluppo
Sede
Manutenzione
Correttiva GP Continuativa
Università
Manutenzione
Adeguativa GP Progettuale
Completo o
ridotto o
Fase Unica
Università
Manutenzione
Evolutiva GP Progettuale
Completo o
ridotto o
Fase Unica
Università
Assistenza Utenti e
Help Desk GP Continuativa
Università
Servizi di Gestione
applicativa e Basi
Dati
GP Continuativa
Università
L‟Università si riserva di modificare le modalità di esecuzione descritte, di
introdurre nuove modalità, di definire/modificare gli attuali standard, anche in
corso d‟opera,dandone congruo preavviso al fornitore. Tali modalità di
esecuzione, potranno essere congiuntamente riviste anche su proposta del
fornitore, e potranno essere concordate opportune semplificazioni o variazioni in
funzione delle specificità dei singoli obiettivi.
Inoltre l‟Università si riserva di chiedere al fornitore di utilizzare prodotti o
modulistica specifica, di supporto alla gestione delle attività della fornitura (ad
esempio: registrazione errori, log interventi, richiesta attività, ecc. ).
L‟Università può avvalersi di terzi per le attività di propria competenza e per
quelle di competenza del Fornitore, ferma restando la loro responsabilità nello
svolgimento di tali attività.
Segue una descrizione più dettagliata delle modalità e degli istituti previsti per
l‟esecuzione dei servizi.
4.1.1 Modalità progettuale
Università La Sapienza di Roma – Capitolato di Gara pag. 35
I servizi di Manutenzione evolutiva e Adeguativa sono erogati in modalità
progettuale, ogni progetto manutentivo si compone di due fasi, la prima fase
include le attività di ricezione dell‟esigenza, stima e autorizzazione.
La seconda fase include le attività di attivazione , consegna , approvazione e
accettazione, il tempo di implementazione è il tempo decorrente tra l‟attività di
attivazione e l‟accettazione.
Le fasi sono delimitate da attività, che sono gli atti, formali o sostanziali, indicati
nella tabella seguente:
FA
SE
1 Attività Attore Descrizione
Segnalazione
Esigenza Ateneo
Comunicazione al RUP dell‟esigenza di avvio di
un servizio di manutenzione evolutiva o
adeguativa
Stima e
Autorizzazione RUP
Comunicazione dei tempi e dei costi in Gp
previsti per il servizio ed autorizzazione a
procedere
FA
SE
2
Attivazione RUP Avvio del Fornitore a procedere con le attività di
sviluppo
Consegna Fornitore
Rilascio dei prodotti di fornitura,sia intermedi
che finali
RUP Riscontro dei prodotti consegnati in quantità.
Approvazione Utente e Rup Validazione dei prodotti intermedi di fornitura,
previa verifica di merito
Accettazione Utente e Rup
Validazione dei prodotti finali di fornitura,
previa verifica di conformità (l‟accettazione è
l‟ultima approvazione del ciclo)
Per ogni progetto di manutenzione sono previste diverse modalità di sviluppo,
come specificato di seguito.
4.1.1.1 Manutenzione evolutiva e manutenzione adeguativa
Per quanto riguarda la manutenzione evolutiva e manutenzione adeguativa, sono
fissati i seguenti criteri oggettivi che orientano nell‟individuare quando applicare
il ciclo di sviluppo appropriato:
Università La Sapienza di Roma – Capitolato di Gara pag. 36
Dimensioni in GP
DU
RA
TA
< 20 < 40 40 -100 > 100
< 15 gg Fase unica Non applicabile Non applicabile Non applicabile
15gg-1 mese Ridotto Ridotto Ridotto Non applicabile
1-3 mesi Non applicabile Ridotto Completo Completo
> 3 mesi Non applicabile Non applicabile Completo Completo
Non applicabile significa che tale situazione non è ritenuta tecnicamente adeguata.
Nei restanti casi invece non sempre tali criteri sono di aiuto, in quanto la scelta più
appropriata può dipendere dalle specifiche caratteristiche dell‟Obiettivo.
Il miglior ciclo di sviluppo pertanto verrà concordato nella fase di Definizione del
progetto.
Il ciclo a fase unica è previsto, di norma, solo in caso di durata non superiore a 15
giorni; in tale circostanza è richiesto al Fornitore un adeguato grado di flessibilità
nella propria organizzazione al fine di garantire la realizzazione con tempi di
intervento brevi.
4.1.1.1.1 Ciclo di sviluppo completo
E‟ la modalità più comunemente adottata per lo sviluppo di applicazioni
gestionali.
La tabella che segue ha lo scopo di essere di riferimento per le varie fasi che
dovranno essere svolte dal Fornitore, associando a ciascuna di esse i prodotti di
fornitura ed il criterio di uscita di fase.
Fase Prodotto di Fase Criterio di uscita
Definizione Specifiche requisiti (ove previsto) Autorizzazione
Piano di lavoro del progetto
Analisi Specifiche funzionali Approvazione
Prototipo(ove previsto)
Piano di Test
Disegno Disegno di dettaglio Approvazione
Piano di Test
Prototipo(ove previsto)
Realizzazione Codice Sorgente Consegna
Piano di Test
Documentazione utente
Manuale di gestione
Verifica di conformità Applicazione Accettazione
Università La Sapienza di Roma – Capitolato di Gara pag. 37
La fase di definizione richiede un‟alta interazione con il personale di Infosapienza
e dell‟Amministrazione al fine di pervenire, in tempi comunque brevi, pur
commisurati alle caratteristiche dell‟intervento,alla formalizzazione completa del
progetto, concordando le stime di impegno, le modalità tecniche di realizzazione,
nonché l‟applicabilità di alcuni prodotti (prototipo e campione tecnico).
L‟attività di raccolta dei requisiti, quando richiede l‟interazione con gli utenti,
verrà svolta congiuntamente a personale Infosapienza e/o dell‟Ateneo.
Anche durante la fase di analisi dovrà essere documentata, sotto forma di verbale,
l‟attività di incontri con gli utenti. Il documento di specifiche funzionali, e il
prototipo, ove previsto, prodotti in fase di analisi, sono soggetti a verifica di
Inofsapienza, e dell‟utente.
La fase di verifica di conformità comprende, la predisposizione della scheda con
le informazioni necessarie agli utenti del sistema per l‟esecuzione della verifica di
conformità, il supporto all‟installazione negli ambienti delle procedure realizzate,
il supporto „on site‟ durante le fasi della verifica di conformità stesso e la
rimozione di eventuali anomalie fino al momento dell‟accettazione.
La verifica di conformità verrà svolta, congiuntamente agli utenti del sistema,
secondo un piano di collaudo, che potrà avere come base il piano dei test prodotto
dal Fornitore, cui potranno essere aggiunti ulteriori casi definiti da Infosapienza
e/o dall‟utente. Durante la fase di verifica di conformità il fornitore dovrà rendere
disponibili le risorse adeguate in termini di numero e skill, per supportare „on site‟
l‟Amministrazione e Infosapienza nell‟esecuzione della stessa verifica di
conformità.
4.1.1.1.2 Ciclo di sviluppo ridotto
E‟ applicabile per obiettivi di dimensioni limitate, sia in termini di effort
progettuale che in termini temporali, come indicato nel paragrafo 5.1.1. del
Capitolato.
La tabella che segue ha lo scopo di essere di riferimento per le varie fasi che
dovranno essere svolte dal Fornitore , associando a ciascuna di esse i prodotti di
fornitura ed il criterio di uscita di fase.
Fase Prodotto di Fase Criterio di uscita
Definizione Specifiche requisiti (ove previsto) Autorizzazione
Piano di lavoro del progetto
Analisi e Disegno Specifiche dell‟intervento Approvazione
Piano di Test
Realizzazione Codice Sorgente Consegna
Piano di Test
Documentazione utente
Manuale di gestione
Verifica di conformità Applicazione Accettazione
Università La Sapienza di Roma – Capitolato di Gara pag. 38
Le differenze rispetto al ciclo di sviluppo completo sono riportate di seguito.
Al fine di snellire l‟iter, l‟attivazione è un documento formale che autorizza il
Fornitore a procedere salvo comunicazione da inoltrare in corso di definizione o
di analisi.
Il documento “Specifiche requisiti”, se previsto quale output della fase, potrà
avere dei contenuti semplificati, pur salvaguardando la comprensibilità e la
consistenza dei contenuti. I contenuti specifici verranno definiti in fase di
definizione.
Le attività relative ad analisi e disegno sono raggruppate in un‟unica fase. Inoltre i
documenti “specifiche funzionali” e “disegno di dettaglio” saranno realizzati in un
unico documento (specifiche dell‟intervento), che quindi raggrupperà sia gli
aspetti funzionali che gli aspetti più tecnici. I contenuti specifici verranno definiti
in fase di definizione.
Al termine della fase di “Analisi e disegno”, Infosapienza verificherà la
corrispondenza del documento alle esigenze dell‟utente, eventualmente
sottoponendolo alla verifica utente. La fase di “Analisi e disegno” si intenderà
conclusa solo dopo l‟esito positivo di tale verifica (approvazione).
4.1.1.1.3 Ciclo a fase unica
E‟ costituito da un‟unica fase, di responsabilità del fornitore, che si conclude con
l‟accettazione dell‟intervento, effettuata da parte del responsabile Infosapienza.
La formalizzazione dei requisiti avviene in forma di verbale.
Tale ciclo è applicabile secondo le indicazioni presenti nel paragrafo 5.1.1 del
Capitolato.
La documentazione potrà essere prodotta dopo la consegna del software
salvaguardando comunque gli aspetti relativi alla messa in esercizio, le cui
indicazioni potranno preliminarmente assumere la caratteristica di un addendum o
di note operative.
Entro i 10 giorni successivi alla consegna del software dovrà essere prodotta
l‟intera documentazione, ed in particolare dovranno essere aggiornati il manuale
utente, il manuale di gestione e l‟inventario funzionale.
Proprio per la natura di questi interventi, non è possibile ipotizzare una loro
pianificazione nell‟arco della fornitura, e quindi è richiesto al fornitore un
adeguato grado di flessibilità nella propria organizzazione al fine di garantire la
realizzazione con tempi di intervento estremamente brevi.
Università La Sapienza di Roma – Capitolato di Gara pag. 39
4.1.2 Modalità continuativa
I servizi oggetto della fornitura da erogare in modalità continuativa non sono
scomponibili in fasi.
L‟attivazione è prevista a partire dalla “data di inizio servizio” e l‟erogazione è
senza soluzione di continuità fino alla data di fine fornitura.
4.1.2.1 Manutenzione Correttiva
Il servizio di manutenzione correttiva, anche se attivato su specifico evento
scaturito da un malfunzionamento, viene erogato in modalità continuativa in
quanto lo specifico evento non è pianificabile.
Ogni segnalazione di malfunzionamento costituisce richiesta di intervento di
manutenzione correttiva.
La discriminazione tra malfunzionamento e nuova esigenza è determinata dall‟
Universita sulla base della documentazione esistente o, per quanto non rilevabile
dalla documentazione (ad esempio contenuti della base dati), dai controlli
effettuati durante l‟attività amministrativa. Nei casi di carenza di documentazione
l‟attribuzione verrà fatta secondo regole di correttezza, buona fede e
ragionevolezza tecnica, in nessun caso l‟onerosità della soluzione potrà essere
valutata quale discriminante.
Dal momento in cui la richiesta è comunicata al Fornitore decorrono i tempi
relativi ai livelli di servizio, il Fornitore ha la responsabilità della esecuzione
dell‟attività ed è tenuto ad aggiornare le informazioni di propria competenza, fino
alla soluzione del malfunzionamento.
La Manutenzione correttiva dovrà prevedere, oltre alla soluzione del
malfunzionamento, anche l‟eventuale ripristino della base dati (tramite
programmi, utilità, routine, ecc) e l‟eventuale aggiornamento della relativa
documentazione, se necessario.
La fine attività verrà comunicata all‟ Università, che si riserva di procedere alla
verificà della conformità delle eventuali modifiche apportate a software,
documentazione e base dati. Diverse modalità di accettazione del servizio
verranno congiuntamente concordate.
Come per il servizio di gestione, anche per la manutenzione correttiva si
sottolinea l‟importanza della presa in carico del sistema a inizio contratto e delle
nuove funzionalità sviluppate man mano, per acquisire un elevato grado di
conoscenza del disegno e del codice realizzato.
Università La Sapienza di Roma – Capitolato di Gara pag. 40
4.1.2.2 Assistenza Utenti e Help Desk
I servizi di supporto agli utenti sono caratterizzati da attività che sono pianificabili
già ad inizio fornitura e da altre che, in funzione delle esigenze che si verranno a
definire nel periodo di durata della fornitura stessa, potranno aggiungersi man
mano (come ad esempio l‟avviamento in esercizio di una nuova applicazione) e
che l‟Università comunicherà con il massimo anticipo possibile.
Il diretto e assiduo contatto con l‟utente nelle attività di supporto richiede alle
risorse dedicate al servizio oltre alle capacità tecniche e professionali (prontezza,
precisione, affidabilità e competenza nell‟individuazione e risoluzione dei
problemi) anche una elevata capacità di relazione.
È essenziale perciò da parte del Fornitore un elevato grado di flessibilità nel
rendere disponibili le risorse, nonché nel garantire le necessarie competenze. In
particolare si sottolinea l‟importanza dell‟addestramento degli utenti al momento
del rilascio in esercizio di nuove funzionalità.
Periodicamente dovrà essere rilevato il grado di soddisfazione degli utenti,
l‟effettiva utilità del supporto agli utenti ed il raggiungimento degli obiettivi.
E‟ richiesto al Fornitore l‟aggiornamento del manuale utente, anche in riferimento
alla versione precedente la fornitura oggetto del presente capitolato.
4.1.2.3 Gestione applicativi e Basi Dati
Il servizio di Gestione applicativi e basi dati rappresenta il riferimento al quale gli
utenti si potranno rivolgere, per tutte le esigenze che si presentano nell‟utilizzo del
sistema informativo. Esso dovrà sempre essere in grado di fornire una risposta,
adeguatamente differenziata in funzione delle tipologie di servizi richiesti (es.
segnalazione malfunzionamenti, richiesta di prodotti/servizio, (esigenze di
addestramento all‟utilizzo delle funzioni presso gli uffici, ecc.).
Il diretto e assiduo contatto con l‟utente nelle attività di front end richiede alle
risorse dedicate al servizio una elevata capacità di analisi, al fine di individuare la
soluzione più idonea a risolvere l‟esigenza utente ed in linea con le strategie
evolutive del sistema informativo. È inoltre indispensabile la capacità di relazione
con le diverse strutture al fine di coinvolgere i supporti più adeguati, anche
creando sinergie con gli altri gruppi di lavoro che operano su progetti diversi.
Le attività estemporanee, normalmente caratterizzate da carattere di urgenza (di
norma, prodotti/servizio) verranno comunicate dal responsabile di Infosapienza
secondo la modalità più idonea (fax, e-mail, telefono) e dovranno essere attivate
dal Fornitore nel più breve tempo possibile. Le situazioni di criticità e urgenza in
cui è possibile che debbano essere svolte le attività, richiedono elevate capacità
tecniche e professionali: prontezza, precisione, affidabilità e competenza.
Università La Sapienza di Roma – Capitolato di Gara pag. 41
È essenziale perciò da parte del Fornitore un elevato grado di flessibilità nel
rendere disponibili le risorse, nonché nel garantire le necessarie competenze. In
particolare si sottolinea l‟importanza della presa in carico del sistema a inizio
contratto e delle nuove funzionalità sviluppate man mano, per acquisire un elevato
grado di conoscenza funzionale ed operativa del software realizzato.
4.2 Orario di Lavoro
Per tutti i servizi oggetto della fornitura il personale del Fornitore dovrà osservare
il seguente orario dal Lunedì al Venerdì di tutti i giorni non festivi , 8 ore da
erogare nella fascia oraria 8.00 – 18.30, le 8 ore vanno intese eventuale pausa
pranzo esclusa, la pausa pranzo fruibile nell‟intervallo tra le ore 13.00 e le ore
15.00 della durata minima di 30 minuti fino ad un massimo di 1 ora.
I periodi di ferie vanno concordate con il responsabile di Infosapienza anche in
relazione alla esigenze dell‟Università.
In caso di assenza per ferie, malattie, indisponibilità in genere della persona
impiegata nel servizio, l‟Università può richiedere una sostituzione temporanea
della persona con un‟altra di livello equivalente.
4.2.1 Verifica della presenza
L‟Università indicherà all‟Impresa – dopo la stipula del contratto - le modalità con
le quali le risorse del Fornitore dovranno certificare la propria presenza presso le
sedi dell‟Ateneo, attraverso la rilevazione degli orari di ingresso ed uscita dagli
stabili – e come tali presenze dovranno essere rendicontate all‟Università.
Mensilmente il Fornitore predisporrà il rendiconto delle giornate erogate.
4.2.2 Luogo di lavoro
I servizi oggetto della fornitura saranno svolti presso le sedi dell‟Università.
L‟Università renderà disponibile al Fornitore il servizio di posta elettronica,
tramite la definizione di caselle di progetto su serventi dell‟Università.
Le postazioni di lavoro sono messe a dispozione dall‟Università.
Università La Sapienza di Roma – Capitolato di Gara pag. 42
5 Livelli di Servizio
Il livello di servizio fornito sarà misurato con cadenza bimestrale e terrà conto del
tempo impiegato dal fornitore per identificare e rimuovere l‟anomalia, rendendone
disponibile il pacchetto correttivo.
Il fornitore dovrà prendere in carico tutte le anomalie presenti e non ancora risolte
alla data di avvio del contratto stesso.
5.1 Definizioni per la misura del livello di servizio
Per il livello di servizio della manutenzione correttiva si definisce periodo di
valutazione (più brevemente “periodo”) un bimestre solare.
Ai fini della misura del livello di servizio si intendono giorni lavorativi i giorni
feriali (i giorni dal lunedì al venerdì non festivi) con orario dalle ore 8.00 alle ore
18.30.
Per segnalazione anomalia si intende la data/ora della segnalazione al fornitore
per l‟assegnazione dell‟anomalia.
Per ripristino in esercizio si intende la data/ora in cui l‟operatività del servizio
verrà ripristinata, previa segnalazione di risoluzione dell‟anomalia e istallazione
del pacchetto correttivo.
Il Tempo di Espletamento (TE) è pari alla differenza tra il ripristino in esercizio
e la comunicazione della segnalazione anomalia.
Relativamente al periodo saranno valutati i tempi di intervento per singola classe
di gravità, con evidenza dei casi nei quali venga superato il cosiddetto Tempo di
Espletamento Massimo (TEM) in relazione alla classe di gravità dell‟anomalia.
Per le anomalie che superano il TEM si considera anche il Coefficiente di
Disservizio (CD) definito come il numero che si ottiene secondo la formula: CD
= TE/TEM.
Per ciascuna anomalia che superi il TEM, il CD viene moltiplicato per il fattore di
normalizzazione relativo alla classe di priorità, secondo la tabella di seguito
riportata:
Classe di priorità/gravità Fattore di normalizzazione (FN)
Immediata 1,2
Urgente 1,1
Alta 1,1
Media 1
Bassa 1
Università La Sapienza di Roma – Capitolato di Gara pag. 43
Il prodotto del CD * FN dà il peso normalizzato (PN) delle anomalie oltre il
TEM, la cui somma determina la somma pesata e normalizzata delle anomalie
oltre il TEM (ΣPN).
Si sommano le anomalie risolte entro il TEM (ΣAE).
Il Livello di servizio si calcola con la seguente formula: Totale delle anomalie nel
periodo / (ΣPN + ΣAE).
Ai fini del calcolo del livello di servizio, eventuali anomalie presenti al momento
di inizio del contratto verranno riassegnate, allineando la “segnalazione anomalia”
alla data di inizio lavori.
5.1.1 Classi di gravità
I malfunzionamenti sul software si suddividono in:
errori bloccanti: fermo di applicazioni critiche, che compromettono il
normale modo di operare dell‟utente e per la quale non esistono soluzioni
alternative. Sono segnalati dalla classe di priorità “Immediata” o
“altissima”.
altri errori: fermo di applicazioni che producono difficoltà al cliente nella
normale gestione, ma che possono avere soluzioni alternative immediate.
Il malfunzionamento può essere recuperato con interventi manuali o
automatici di work around di immediata attivazione che possono essere
attuati solo per brevi periodi di tempo. In base alla rilevanza delle
conseguenze dell‟anomalia possono avere priorità “alta, “media”, “bassa”
che, di volta in volta ed ove possibile, saranno stabilite dal RUP sulla base
dell‟impatto all‟utenza.
Tenendo presente che per “Tempo di intervento” si intende il tempo di presa in
carico del problema e con “Tempo di ripristino” si intende il tempo di ripristino
dell‟operatività del servizio, nella tabella seguente sono indicati i tempi di
espletamento massimi in relazione alla gravità dell‟anomalia.
Eventuali errori generati dal fornitore stesso saranno valutati, dall‟inserimento
della segnalazione al ripristino della funzione, fuori tempo massimo.
Livelli di Servizio
Errori bloccanti
(Priorità immediata
o urgente)
Tempo massimo di intervento 2h nel 90% dei casi
5h nel 10% dei casi
Tempo massimo di risoluzione
dell‟errore
8h nel 90% dei casi
24h nel 10% dei casi
Università La Sapienza di Roma – Capitolato di Gara pag. 44
Tempo massimo di ripristino in
esercizio
Entro 8h solari
successive alla
risoluzione nel 100%
dei casi
Tasso di risoluzione degli errori 100%
Altri errori con
priorità alta o
media
Tempo massimo di intervento 16h nel 90% dei casi
24h nel 10% dei casi
Tempo massimo di risoluzione
dell‟errore
32h nel 90% dei casi
48h nel 10% dei casi
Tempo massimo di ripristino in
esercizio
Entro 8h solari
successive alla
risoluzione nel 100%
dei casi
Percentuale minima di risoluzione
degli errori
99%
Altri errori con
priorità bassa Tempo massimo di intervento
32h nel 90% dei casi
48h nel 10% dei casi
Tempo massimo di risoluzione
dell‟errore
40h nel 90% dei casi
64h nel 10% dei casi
Tempo massimo di ripristino in
esercizio
Entro 8h solari
successive alla
risoluzione nel 100%
dei casi
Percentuale minima di risoluzione
degli errori
99%
Università La Sapienza di Roma – Capitolato di Gara pag. 45
6 Presa in carico e trasferimento
6.1.1 Presa in carico
Nei 3 mesi precedenti la “data di inizio servizio” è data la possibilità al Fornitore
di richiedere all‟ Università di usufruire di addestramento, al fine di permettere al
proprio personale di prendere in carico al meglio i servizi oggetto della fornitura.
Tale addestramento potrà consistere, ad esempio, in riunioni di lavoro, esame
della documentazione esistente con assistenza di personale esperto, affiancamento
nell‟operatività quotidiana di manutenzione correttiva e gestione condotta dal
fornitore uscente, senza peraltro la possibilità di eseguire direttamente le
attività(training on the job).
Le modalità di fruizione e la relativa pianificazione di tale addestramento
dovranno essere concordate con l‟Università, anche sulla base delle proposte che
il Fornitore potrà fare in sede di offerta. L‟Università garantirà la presenza di
personale esperto, che potrà essere sia dell‟Università stessa che di terzi da essa
designati.
6.1.2 Trasferimento di know-how
Nel corso dell‟esecuzione del contratto, in maggior misura negli ultimi 3 mesi di
esecuzione delle attività contrattuali - e fermo restando il successivo periodo di 6
mesi relativi alle sole attività di manutenzione su chiamata - il Fornitore dovrà, su
richiesta dell‟Università, trasferire a personale dell‟Università, o a terzi da essa
designati il know-how sulle attività condotte, al fine di rendere l‟eventuale
prosecuzione delle attività quanto più efficace possibile, secondo un programma
formativo che preveda ad esempio docenze, sessioni riassuntive, sessioni di lavoro
congiunto, presentazioni, tavole rotonde, ecc. su funzioni, disegno, codice e
documentazione del sistema INFOSTUD.
Nell‟ambito di tale programma il Fornitore dovrà , se richiesto, affiancare il
personale del nuovo Fornitore nell‟operatività quotidiana di manutenzione
correttiva e gestione condotta dal fornitore uscente, senza peraltro che questi abbia
la possibilità di eseguire direttamente le attività (training on the job).
Le modalità di erogazione e la relativa pianificazione del trasferimento di know-
how dovranno essere concordate con l‟Università, anche sulla base delle proposte
che il Fornitore potrà fare in sede di offerta. Le attività concordate e pianificate
saranno remunerate, a consumo, all‟atto dell‟avvenuta prestazione
(prodotto/servizio).
Università La Sapienza di Roma – Capitolato di Gara pag. 46
7 Profili professionali richiesti
Le figure professionali proposte per lo svolgimento dei servizi oggetto della
fornitura dovranno fare riferimento ai profili di seguito descritti. Questi hanno
valore indicativo e non prescrittivo, in quanto l‟Università si riserva in ogni caso
di accettare o meno una risorsa per una certa qualifica sulla base delle effettive
capacità, al di là del suo profilo personale.
Ad esempio, 5 anni addizionali di esperienza professionale nel settore informatico
corrispondono ad una cultura equivalente ad una laurea in discipline tecniche.
Ogni riferimento a competenze funzionali ad attività o metodologie basate
sull’adozione di prodotti e ogni riferimento a prodotti vanno intese in relazione ai
prodotti e/o ai componenti di tali prodotti che sono effettivamente adottati nello
sviluppo e nella gestione del sistema SIAD d’Ateneo. Se possedute, queste sono
apprezzate come competenze core per l’esecuzione della fornitura. Competenze su
altri prodotti, non adottati, o su componenti non utilizzate dei prodotti adottati
sono apprezzate in minor misura e comunque solo se associate alle competenze
core.
Tale scenario può cambiare in corso d’opera, in conseguenza dell’evoluzione delle
piattaforme utilizzate. Pertanto, i profili delle figure che seguono non sono da
considerare esaustivi delle esigenze della fornitura, in quanto l’Ateneo potrà
richiedere in corso di esecuzione del contratto competenze specifiche in relazione
ad ulteriori tematiche, prodotti, sistemi e metodologie.
I Curricula vitae del personale, che saranno resi disponibili nei vari servizi oggetto
della fornitura e che dovranno essere consegnati secondo quanto previsto
contrattualmente, dovranno essere predisposti secondo il template indicato in
Appendice A – Template Curriculum Vitae.
Le figure professionali proposte dovranno parlare e scrivere l’italiano in modo
fluente.
Responsabile del servizio
Titolo di studio Laurea in discipline tecniche o cultura equivalente
Esperienze lavorative:
Minimo 12 anni, di cui almeno 4 anni di provata esperienza lavorativa
nella specifica funzione su progetti complessi con periodi di permanenza
continuativa presso lo stesso cliente non inferiori ad 1 anno
Redazione di documentazione di progetto
Controllo realizzazione procedure
Stima di risorse per realizzazione di progetto
Università La Sapienza di Roma – Capitolato di Gara pag. 47
Stima di tempi e pianificazione attività
Analisi e progettazione di sistemi informativi, package, procedure
complesse
Responsabilità su gruppi di progetto
Conoscenze:
Metodologie di sviluppo
Conoscenza delle metriche e delle metodologie per la misura degli stati
d'avanzamento dei progetti
Conoscenze ed uso di tecniche e prodotti software per project management
e risk management
Conoscenza delle tecnologie utilizzate nel progetto con particolare
riferimento ad Oracle As e Oracle DB
Autorevolezza e comprovata esperienza in progetti di grandi dimensioni
Ottime capacità relazionali
Coordinamento di gruppi di lavoro
Tecniche di controllo di progetto
Analista funzionale
Titolo di studio Laurea in discipline tecniche o cultura equivalente
Esperienze lavorative:
Minimo 8 anni, di cui almeno 4 come analista
Redazione di documentazione di progetto
Redazione di modelli dei processi
Controllo realizzazione procedure
Stima di risorse per lo sviluppo di software
Stima di tempi e pianificazione attività
Analisi requisiti utente
Disegno interfacce utente
Disegno e progettazione di test
Partecipazione allo sviluppo/manutenzione di progetti con l'utilizzo di
Oracle As ed Oracle DB
Conoscenze:
Metodologie di analisi di prodotti SW
Università La Sapienza di Roma – Capitolato di Gara pag. 48
Metodologie di analisi dei processi
Metodologie di disegno di prodotti SW
Tecniche di programmazione strutturata
Tecniche di programmazione in ambiente WEB
Tecniche di modellazione e integrazione dati
DBMS Oracle e programmazione in ambiente Oracle
Conoscenza di strumenti di work-flow management
Conoscenza delle tematiche relative alla gestione documentale ed alla
firma digitale
Metodologie e tecniche per il cleaning e la qualità dei dati
Ottime capacità relazionali
Analista programmatore
Titolo di studio Diploma di perito informatico o diploma analogo
Esperienze lavorative:
Minimo 4 anni come programmatore e 3 nella funzione
Coordinamento di piccoli gruppi di lavoro
Verifica della corretta applicazione di metodi e standard
Sviluppo di analisi tecnica di media complessità
Documentazione procedure
Preparazione di casi di test
Esecuzione di test
Partecipazione a gruppi di progetto di medie/grandi dimensioni
Partecipazione allo sviluppo/manutenzione di progetti con l'utilizzo di
Oracle AS
Conoscenze:
Metodologie di disegno di prodotti software
Tecniche di programmazione strutturata
Tecniche di programmazione in ambiente WEB
DBMS relazionali e in particolare Oracle
Strumenti di modellazione dati
Strumenti per il cleaning e la qualità dei dati
Università La Sapienza di Roma – Capitolato di Gara pag. 49
Tecniche di realizzazione di Web Services
Ottima conoscenza di linguaggi di programmazione Java/Pl Sql
Ottime capacità relazionali
Università La Sapienza di Roma – Capitolato di Gara pag. 50
8 Allegati al presente capitolato tecnico
Sono parte integrate del presente capitolato le seguenti appendici:
U-GOV Architettuta, tecnologia e applicazioni – White Paper Luglio 2007
Documento che descrive architettura, tecnologia e applicazioni della
soluzione U-GOV.
Appendice “A” – Template Curriculum Vitae
Template da utilizzare per i curriculum vitae del personale reso disponibile
nei vari servizi oggetto della fornitura.
Appendice “B” – Template Piano d‟Impiego
Template da utilizzare per la composizione del gruppo di lavoro ed il
relativo piano d‟impiego.