Università degli Studi di Roma - uniroma1.it · E parte integrante del capitolato l‟allegato...

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.


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à;


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.


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.


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


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.


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


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


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


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


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


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


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


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.


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


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


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.


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


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.


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.


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.


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)


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


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


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.




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.


previsto per la manutenzione adeguativa.


Impegno in GP

Servizi di manutenzione adeguativa Totale I anno II anno

400 200 200


Per i servizi di manutenzione adeguativa è richiesto al Fornitore l‟impegno di



Analista Funzionale









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.


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


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


Emissione ed incasso delle Tasse

Autocertificazioni

Dati contabili



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.


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


Per i servizi di manutenzione evolutiva è richiesto al Fornitore l‟impegno di



Analista Funzionale










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.


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.




GP l‟impegno necessario al servizio di assistenza utenti e help desk. Al mutare





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





Analista Funzionale










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.


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


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.




GP l‟impegno necessario al servizio di gestione applicativi e basi dati. Al mutare





previsto per la gestione applicativi e della basi dati


Impegno in GP

Servizi di Gestione applicativi e Basi Dati Totale I anno II anno

340 150 190





Analista Funzionale










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


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:


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


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


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.


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.


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.


È 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à.


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


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


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



dell‟errore




esercizio

Entro 8h solari

successive alla


dei casi

Percentuale minima di risoluzione

degli errori

99%

Altri errori con

priorità bassa Tempo massimo di intervento




dell‟errore




esercizio

Entro 8h solari

successive alla


dei casi

Percentuale minima di risoluzione

degli errori

99%


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).


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.


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


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


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


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


Analista programmatore

Titolo di studio Diploma di perito informatico o diploma analogo


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


Tecniche di realizzazione di Web Services

Ottima conoscenza di linguaggi di programmazione Java/Pl Sql



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.

Università degli Studi di Roma - uniroma1.it · E parte integrante del capitolato l‟allegato...

Documents

Transcript of Università degli Studi di Roma - uniroma1.it · E parte integrante del capitolato l‟allegato...