SIAR
SIAR
Sistema Informativo Agricolo Regionale
Bando di gara per la
FORNITURA DI SERVIZI PER LA PROGETTAZIONE E LO SVILUPPO DI APPLICATIVI MONOTEMATICI
Disciplinare tecnico
Xxx Xxxxxx, xxx - 00000 XXXXXXXX - CA tel. 000.0000000 - fax 000.0000000
SOMMARIO
1 Premessa 5
1.1 Acronimi 5
2 Contesto 6
3 Obiettivi 6
4 Requisiti 7
4.1 Requisiti generali 7
4.2 Componente “Patentini Verdi” 7
4.2.1 Obiettivi 7
4.2.2 Normativa di riferimento 7
4.2.3 Soggetti coinvolti 8
4.2.4 Requisiti funzionali 9
4.2.5 Dimensionamento 10
4.3 Componente “Registro informatico debitori” 11
4.3.1 Obiettivi 11
4.3.2 Normativa di riferimento 11
4.3.3 Soggetti coinvolti 11
4.3.4 Requisiti funzionali 11
4.3.5 Dimensionamento 15
4.4 Componente “Albo IAP” 16
4.4.1 Obiettivi 16
4.4.2 Normativa di riferimento 16
4.4.3 Soggetti coinvolti 16
4.4.4 Requisiti funzionali 16
4.4.5 Dimensionamento 17
4.5 Componente “Albo delle Licenze di pesca” 18
4.5.1 Obiettivi 18
4.5.2 Normativa di riferimento 18
4.5.3 Soggetti coinvolti 18
4.5.4 Requisiti funzionali 18
4.5.5 Dimensionamento 20
4.6 Componente “Albo degli operatori agrituristici” 21
4.6.1 Obiettivi 21
4.6.2 Normativa di riferimento 21
4.6.3 Soggetti coinvolti 21
4.6.4 Requisiti funzionali 21
4.6.5 Dimensionamento 23
4.7 Componente “Catalogo Prodotti” 24
4.7.1 Obiettivi 24
4.7.2 Normativa di riferimento 24
4.7.3 Soggetti coinvolti 25
4.7.4 Requisiti funzionali 25
4.7.5 Dimensionamento 28
5 Vincoli 29
5.1 Vincoli tecnologici 29
5.2 Vincoli normativi 29
5.3 Vincoli organizzativi 29
6 Modalità di realizzazione 30
6.1 Raccolta e analisi dei requisiti 31
6.1.1 Obiettivi 31
6.1.2 Deliverables 31
6.2 Progettazione tecnica 32
6.2.1 Obiettivi 32
6.2.2 Deliverables 33
6.3 Sviluppo 35
6.3.1 Obiettivi 35
6.3.2 Deliverables 35
6.4 Integrazione 36
6.4.1 Obiettivi 36
6.4.2 Deliverables 36
6.5 Collaudo 37
6.5.1 Deliverables 37
6.6 Formazione 38
6.6.1 Deliverables 39
6.7 Manutenzione correttiva 39
6.7.1 Obiettivi 39
6.7.2 Deliverables 40
7 Modalità di esecuzione 40
7.1 Gestione del progetto 40
7.1.1 Piano di Progetto 40
7.2 Organizzazione generale del progetto 41
8 Tempi di realizzazione 41
9 Allegati 41
1 Premessa
L’Assessorato Regionale dell’Agricoltura e Riforma Agro-pastorale della Regione Sardegna, in seguito riferito come Assessorato dell’Agricoltura, nel contesto di ammodernamento e attuazione dell’innovazione tecnologica dell’amministrazione regionale ha commissionato la realizzazione del Sistema Informativo Agricolo Regionale (SIAR) che, in cooperazione con altri sistemi informativi regionali e nazionali, porterà alla semplificazione e razionalizzazione dei procedimenti amministrativi.
Per l’esecuzione delle attività previste nel progetto SIAR sono stati stanziati 7 milioni di euro dei quali 5 milioni di euro a valere sulla misura 6.3 – Società dell’informazione – del POR Sardegna 2000-2006 e 2 milioni di euro a valere sui fondi di cui alla delibera CIPE 3/2006.
1.1 Acronimi
- SIAR – Sistema Informativo Agricolo Regionale
- IAP – Imprenditore agricolo professionale
- SIAN – Sistema Informativo Agricolo Nazionale
- D.A.D.A. – Decreto dell'Assessore regionale per la Difesa dell'Ambiente
- MIPAF – Ministero delle Politiche Agricole Alimentari e Forestali
2 Contesto
Il Sistema Informativo Agricolo Regionale (SIAR) è stato avviato nel corso del 2007 ed è considerato un progetto pilota a livello nazionale per il suo grado di innovazione e di cooperazione con il Sistema Informativo Agricolo Nazionale (SIAN), pertanto La Regione Autonoma della Sardegna si candida ad essere un punto di riferimento per altre amministrazioni che intendano percorrere la medesima esperienza di integrazione con il SIAN. Il Sistema Informativo Agricolo Regionale comprende una serie di servizi per l’attuazione del concreto supporto e del dialogo virtuale tra amministrazione e utenti. Esso esprime strumenti come l’Anagrafe regionale delle aziende agricole, che rappresentano un momento di razionalizzazione del flusso di informazioni da parte delle aziende agricole che consente di avere, per ciascuna, un'esatta fotografia della sua situazione e di ridurre la presentazione dei documenti cartacei, semplificando così gli adempimenti burocratici e garantendo una maggiore trasparenza dei procedimenti amministrativi. L’anagrafe, fra le atre cose, offre la possibilità di individuare univocamente una azienda agricola e di associarla ai procedimenti amministrativi cui ha partecipato, al fine di realizzare la gestione informatizzata e razionale di tutti i procedimenti inerenti l’agricoltura sarda. L’attuazione delle disposizioni normative in tema di semplificazione amministrativa in agricoltura e trasferimento delle competenze e delle funzioni a favore delle Province e delle tre Agenzie Regionali AGRIS, LAORE e ARGEA, unitamente alle esigenze derivanti dall’evoluzione con il SIAN, impongono l’ampliamento dei servizi già erogati dal SIAR. Ad oggi il Sistema Informativo Agricolo Regionale ha raggiunto un grado di maturità che consente l’erogazione dei servizi ad enti e amministrazioni diverse da quella Regionale, nonché alle singole aziende agricole e al cittadino. L’estensione dei servizi SIAR favorirà il consolidamento del portale web della Regione Autonoma della Sardegna dedicato all’agricoltura, già fruibile attraverso la rete Internet, che sarà esteso con la progressiva pubblicazione dei nuovi servizi. Il portale tematico dell’agricoltura rappresenterà il punto unico di accesso ai servizi erogati dal SIAR Sardegna. Il SIAR deve inoltre garantire l’interoperabilità con i sistemi informativi di altre amministrazioni, allo scopo di condividere servizi e favorire la semplificazione dei procedimenti amministrativi e di certificazione delle informazioni. Fra le principali collaborazioni già avviate si evidenziano quelle con il SIAN e con il Sistema Informativo Territoriale della Regione Sardegna (SITR).
3 Obiettivi
Con il presente appalto l’Amministrazione intende selezionare un fornitore per la progettazione e sviluppo delle seguenti componenti applicative:
1. Componente per la gestione del rilascio dei Patentini Xxxxx;
2. Componente per la gestione del Registro informatico debitori;
3. Componente per la gestione dell’Albo IAP;
4. Componente per la gestione dell’Albo delle Licenze di pesca;
5. Componente per la gestione dell’Albo degli operatori agrituristici;
6. Componente per la gestione del Catalogo dei prodotti agroalimentari.
4 Requisiti
4.1 Requisiti generali
Le componenti richieste devono integrarsi perfettamente e organicamente nel Sistema Informativo Agricolo Regionale (SIAR) e consentire l’erogazione via web del servizio per cui sono state commissionate. Nelle pagine seguenti saranno dettagliati i requisiti e i vincoli tecnici generali e particolari da rispettare nella progettazione nello sviluppo delle componenti applicative. Si precisa che i requisiti riportati di seguito rappresentano la base per la formulazione della proposta tecnico- economica, ma non sono da considerarsi esaustivi e sufficienti per l’avvio dell’attività di progettazione e sviluppo delle componenti richieste. I seguenti requisiti dovranno essere ripresi, approfonditi e formalizzati in sede di esecuzione dei lavori.
Per ciascuna delle componenti richieste dovrà essere effettuata un’attività di migrazione dati per trasferire sul nuovo componente applicativo i dati registrati in formato elettronico (database, fogli elettronici, etc.) utilizzati fino al momento dell’attivazione del componente.
4.2 Componente “Patentini Verdi”
4.2.1 Obiettivi
Il componente deve consentire la gestione informatizzata del procedimento di rilascio delle autorizzazioni all’acquisto di prodotti fitosanitari tossici e nocivi (Rilascio Patentini Verdi) attraverso un applicativo web inserito nel sistema informativo agricolo regionale.
4.2.2 Normativa di riferimento
A seguito del trasferimento delle competenze dall’Amministrazione regionale alle province, il rilascio del Patentino verde è a carico della Provincia di residenza del richiedente.
La normativa di riferimento è la seguente:
- Decreto del Presidente della Repubblica 23 aprile 2001, n.290 - Regolamento di semplificazione dei procedimenti di autorizzazione alla produzione, alla immissione in commercio e alla vendita di prodotti fitosanitari e relativi coadiuvanti
- Deliberazione della Giunta regionale del 30.4.2002 n. 13/1.
4.2.3 Soggetti coinvolti
Province della Sardegna: enti responsabili dello svolgimento del procedimento di rilascio del patentino verde;
Assessorato dell’Agricoltura: ente delegato dallo stato per l’emissione delle autorizzazioni all’acquisto di prodotti fitosanitari tossici e nocivi, che ha trasferito le sue competenze alle province;
Xxxxxxx XXXXX Sardegna: ente incaricato dell’organizzazione e dello svolgimento dei corsi di formazione per l’esame di idoneità al rilascio del patentino verde;
Richiedenti: persone fisiche che richiedono il rilascio del Patentino verde;
Detentori: persone fisiche in possesso di Patentino verde in corso di validità x xxxxxxx.
4.2.4 Requisiti funzionali
Il processo di rilascio del patentino verde, da automatizzare con il presente componente, è il seguente:
1. il Richiedente si presenta all’Ufficio Provinciale designato al rilascio dei patentini verdi e inoltra la
Domanda di rilascio;
2. l’Ufficio Provinciale acquisisce la domanda e avvia il procedimento di rilascio secondo la seguente regola:
- se il richiedente appartiene a una categoria autorizzata per legge al possesso del patentino verde (es. Agronomi, Periti agrari, etc.), l’istruttore completa il procedimento e rilascia il Patentino;
- se il richiedente non appartiene a una categoria autorizzata per legge al possesso del patentino verde, l’istruttore porta avanti il procedimento con l’iscrizione del richiedente nella lista d’attesa dei partecipanti al successivo corso di formazione e al relativo esame di idoneità;
3. l’ufficio di XXXXX effettua la consultazione via web delle liste d’attesa degli iscritti ai corsi, al fine di pianificare lo svolgimento degli stessi;
4. il Richiedente frequenta il corso di formazione organizzato da XXXXX e sostiene il relativo esame finale organizzato dalla Provincia;
5. l’Ufficio Provinciale immette sull’applicativo i dati riportati nel verbale d’esame, predisposto dalla commissione esaminatrice, contenente l’esito dell’esame medesimo;
6. l’Ufficio Provinciale completa il procedimento con il rilascio del Patentino a tutti i richiedenti che sono stati indicati idonei nel verbale d’esame.
Altre funzionalità richieste all’applicativo:
- all’atto del rilascio, deve assegnare al Patentino verde un numero univoco per Provincia
(es. VS000153);
- deve calcolare, mostrare e segnalare la data di scadenza del Patentino riepilogando in un
elenco i patentini in scadenza in un determinato intervallo di tempo impostabile dall’utente;
- deve consentire l’immissione, la gestione e la stampa di una proroga sul periodo di validità del Patentino;
- deve consentire il rinnovo del patentino attraverso la ripetizione del procedimento di rilascio su una posizione anagrafica già presente perché già in possesso di un patentino scaduto. Se necessario deve consentire l’aggiornamento della posizione anagrafica e la storicizzazione dei dati modificati;
- deve consentire la revoca di un Patentino;
- deve consentire la stampa del duplicato di un Patentino e l’inserimento delle motivazioni che la giustificano;
- deve essere parametrizzabile, in modo da presentare le pagine e le stampe in funzione dell’ente di appartenenza dell’utente che lo utilizza. Ad esempio, la stampa del patentino deve presentare nell’intestazione il logo e i dati corrispondenti alla Provincia che effettua il rilascio;
- deve utilizzare i web services del SIAN per l’accesso ai dati anagrafici forniti dall’Anagrafe Tributaria. Tali dati saranno usati, a partire dal codice fiscale del richiedente, per il pre- popolamento e validazione della scheda anagrafica del procedimento di rilascio del patentino verde.
4.2.5 Dimensionamento
Di seguito si indicano i volumi da gestire:
- 10.000 patentini rilasciati fino ad oggi;
- 1.000 patentini rilasciati ogni anno su tutto il territorio regionale;
- 50 utenti previsti per l’utilizzo dell’applicativo.
4.3 Componente “Registro informatico debitori”
4.3.1 Obiettivi
Il componente deve consentire la gestione informatizzata del registro debitori e dei processi di notifica attraverso un applicativo web inserito nel SIAR.
4.3.2 Normativa di riferimento
- L.R.11/06 “Norme in materia di programmazione, di bilancio e di contabilità della Regione autonoma della Sardegna. Abrogazione delle leggi regionali 7 luglio 1975, n. 27, 5 maggio 1983, n. 11 e 9 giugno 1999, n. 23”.
- L.R. 44/88 del 13 dicembre 1988, “Costituzione del fondo regionale di garanzia per l’agricoltura e provvidenze per l’agricoltura”
4.3.3 Soggetti coinvolti
Debitore: azienda o imprenditore agricolo che si trova in posizione di debito nei confronti dell’Amministrazione regionale.
Assessorato dell’Agricoltura e ARGEA Sardegna: gestiscono l’istruttoria dei finanziamenti, le revoche dei contributi e la procedura di verifica della posizione dei debitori e necessitano di conoscere l’eventuale posizione d’insolvenza dei debitori dell’Assessorato per valutare l’assegnazione dei finanziamenti e dei contributi gestiti.
4.3.4 Requisiti funzionali
Un’azienda, un imprenditore agricolo o un ente possono trovarsi in posizione debitrice nei confronti dell’Amministrazione regionale e, nel caso specifico, dell’Assessorato dell’Agricoltura, quando gli vengono revocati dei finanziamenti per i quali hanno già ricevuto dei contributi.
Il componente applicativo richiesto deve supportare le diverse procedure previste nel processo di revoca di un finanziamento, di cui in seguito si descrivono le principali:
Procedura di messa in mora
1. L’Assessorato rileva l’esistenza delle condizioni per la revoca di un finanziamento ad un’azienda ed emette una Determinazione di revoca, che viene trasmessa al debitore per informarlo della sua posizione.
2. L’Assessorato procede con la messa in mora del debitore, comunicandogli:
- il termine di pagamento (tipicamente 30gg);
- l’importo dovuto, corrispondente alla somma:
▪ dell’importo già percepito per il finanziamento accordato;
▪ degli interessi dovuti, calcolati in base ad un tasso di interesse legato al procedimento e al periodo in cui era stato rilasciato il credito.
3. Dopo la messa in mora, il debitore può:
- Estinguere il debito: in questo caso, l’Assessorato esegue una verifica contabile e nel caso riscontri che il pagamento sia stato effettivamente e correttamente eseguito aggiorna la situazione del debitore estinguendo il suo debito.
- Chiedere una rateizzazione del debito.
Procedura di ingiunzione fiscale
Una volta scaduto il termine di pagamento, l’Assessorato effettua una verifica sull’eventuale copertura assicurativa del debitore.
1. Nel caso in cui il debitore sia coperto da polizza assicurativa, l’Assessorato richiede il pagamento all’Assicurazione del debitore:
- Se l’assicurazione paga, l’Assessorato emette una quietanza di pagamento. Nel caso l’assicurazione estingua solo una parte del debito, la parte restante sarà comunque richiesta direttamente al debitore.
- Se l’assicurazione non paga, l’Assessorato procede con l’ingiunzione fiscale.
2. Nel caso in cui il debitore non sia coperto da polizza assicurativa, l’Assessorato:
- Individua i beni del debitore da sottoporre a pignoramento, tramite una visura in conservatoria e/o recuperando documenti da altri Servizi e Assessorati.
- Procede con un’ingiunzione, includendo le spese di visura e di notifica. L’ingiunzione fiscale deve essere stampata e registrata.
3. L’Assessorato procede con la verifica contabile:
- Se il debitore ha pagato, il debito viene estinto, altrimenti, procede con la determinazione di pignoramento, che in base all’entità del debito può essere immobiliare o mobiliare.
- Se il debitore richiede la rateizzazione del debito, l’Assessorato non procede con il pignoramento.
Procedura di rateizzazione del debito
1. Il debitore può richiedere una rateizzazione del debito sia dopo la messa in mora sia dopo l’ingiunzione fiscale di pagamento.
2. L’Assessorato formalizza il piano di restituzione del debito accompagnato da una “lettera tipo” e la propone per l’approvazione alla Giunta Regionale o al Direttore del Servizio, in base all’entità del debito. Il piano di rateizzazione include anche gli interessi sull’importo rateizzato.
3. La Giunta Regionale o il Direttore del Servizio verificano ed eventualmente approvano il piano di restituzione.
4. L’Assessorato
- Comunica al debitore il piano di rateizzazione, calcolato ed approvato.
- Compila lo scadenzario per il debitore, con gli importi dovuti e le date di scadenza di ogni rata.
5. Ad ogni scadenza pattuita, l’Assessorato verifica se il debitore ha inviato la ricevuta di pagamento:
- Se la ricevuta è stata correttamente inviata, aggiorna la situazione contabile del debitore.
- Se la ricevuta non è stata inviata, l’Assessorato compie delle verifiche per capire se si tratta di un ritardo o di un mancato pagamento. In caso di mancato pagamento, si procede nuovamente con la messa in mora del debitore, facendo decadere il piano di restituzione.
Procedura di calcolo degli interessi:
La procedura di calcolo prevede:
1. La selezione di un tasso di interesse da applicare, in base al tipo di procedimento che ha generato il debito e al periodo in cui è stato erogato. Il tipo di tasso può variare nel corso dell’esistenza del debito.
2. Il calcolo dell’interesse sul capitale dovuto, per il periodo concesso nella messa in mora per la restituzione del debito.
Procedura di compensazione del debito:
1. In caso di messa in mora di un debitore, l’Assessorato può contattare gli uffici territoriali dell’ARGEA o altri Assessorati per verificare se sono previste elargizioni di contributi a favore di quel debitore. In tal caso, è possibile effettuare una compensazione:
a. Il nuovo contributo viene decurtato della somma necessaria per coprire totalmente o parzialmente il debito.
b. In caso di compensazione parziale, l’Assessorato ripete l’iter dalla messa in mora per il debito residuo.
In caso di compensazione totale, la posizione del debitore viene aggiornata e il suo debito estinto.
Reportistica prevista
- Determinazione di revoca, da inviare al debitore;
- Lettera di trasmissione della determinazione di revoca;
- Lettera di messa in mora;
- Sollecito di pagamento;
- Ingiunzione fiscale;
- Lettera di accompagnamento dell’ingiunzione fiscale;
- Schema di rateizzazione del debito;
- Prospetto per il dettaglio del calcolo dell’interesse dovuto.
Altre funzionalità richieste all’applicativo:
Ricorso da parte del debitore: il debitore può opporsi alla messa in mora o all’ingiunzione fiscale; in tal caso è necessario l’intervento dell’area legale della Presidenza della Giunta e s’instaura un contenzioso tra le parti.
4.3.5 Dimensionamento
Il volume esatto di debitori sarà determinato in fase di analisi. A titolo indicativo è possibile fornire una stima dei debitori derivanti dalla revoca dei contributi concessi con la L.R. 44/88 che ammonta a 5400 debitori.
4.4 Componente “Albo IAP”
4.4.1 Obiettivi
Il componente deve consentire la gestione informatizzata del procedimento di iscrizione all’elenco regionale degli Imprenditori Agricoli Professionali (Albo IAP).
4.4.2 Normativa di riferimento
- L.R. 12 giugno 2006, n. 9 “Conferimento di funzioni e compiti agli enti locali”, articolo 35, lettera c);
- Articolo 1 del D.Lgs. 29 marzo 2004, n. 99, modificato dal D.Lgs. n. 101/2005;
- Delibera della Giunta regionale n. 45/9 del 27 settembre 2005, “Disciplina per il riconoscimento della qualifica di imprenditore agricolo professionale (I.A.P.), X.Xxx. 29 marzo 2004, n. 99 integrato e modificato dal D.Lgs. 27 maggio 2005, n. 101”;
- Delibera della Giunta regionale n. 23/1 del 16 aprile 2008, “Riconoscimento della qualifica di imprenditore agricolo professionale (I.A.P.). D.Lgs. 29 marzo 2004, n. 99 integrato e modificato dal D.Lgs. 27 maggio 2005, n. 101”.
4.4.3 Soggetti coinvolti
Richiedente: persona fisica o giuridica che richiede l’iscrizione all’albo regionale IAP.
Province della Sardegna con il ruolo di:
- operatore, per l’inserimento della domanda;
- istruttore, per la gestione della fase istruttoria e il rilascio della certificazione;
- lettore, per la ricerca e la visualizzazione delle informazioni e la stampa degli elenchi.
Assessorato dell’Agricoltura o ARGEA Sardegna: aventi ruolo di lettore, per la ricerca e la visualizzazione delle informazioni e la stampa dell’albo regionale.
4.4.4 Requisiti funzionali
Il processo di iscrizione all’Albo IAP, da automatizzare con l’applicativo web, è il seguente:
1. il Richiedente presenta alla Provincia la domanda di iscrizione all’Albo IAP;
2. la Provincia carica a sistema i dati riportati nella domanda;
3. la Provincia avvia l’istruttoria per l’iscrizione all’albo e il rilascio del relativo certificato, con l’esecuzione della verifica (attraverso una checklist dei requisiti) sul possesso di determinati
requisiti, legati al reddito e alle competenze professionali del richiedente:
a) Se le verifiche hanno esito positivo, il richiedente è iscritto al registro IAP e gli viene rilasciata la relativa certificazione;
b) Se le verifiche non hanno esito positivo:
- il richiedente che si impegna ad acquisire i requisiti mancanti entro 24 mesi dal rilascio, è iscritto al registro IAP e gli viene rilasciata la relativa certificazione “sotto condizione”;
- il procedimento viene chiuso con esito negativo e non avviene alcuna iscrizione al registro IAP.
4. Per certificazioni “sotto condizione”:
a) il Richiedente presenta, entro 24 mesi, alla Provincia la documentazione che attesta il possesso dei requisiti non soddisfatti al momento dell’iscrizione al registro;
b) La Provincia, allo scadere dei 24 mesi, verifica l’acquisizione dei requisiti mancanti:
- Se l’esito della verifica è positivo, lo stato “sotto condizione” viene eliminato e l’iscrizione all’albo diventa definitiva;
- Se l’esito della verifica è negativo, si procede alla radiazione dall’albo. In tal caso la Provincia informa esplicitamente il richiedente della revoca della certificazione e della radiazione dall’albo.
Altre funzionalità richieste all’applicativo:
- stampa in formato pdf della documentazione necessaria a supportare il procedimento: certificazioni, notifiche, registro, etc.;
- gestione scadenzario delle certificazioni “sotto condizione”.
4.4.5 Dimensionamento
Di seguito si indicano i volumi da gestire:
- 250 iscrizioni per il 2007, presenti sull’applicativo attualmente in esercizio;
- 25 operatori degli ex servizi ripartimentali, che eseguono le registrazioni.
4.5 Componente “Albo delle Licenze di pesca”
4.5.1 Obiettivi
Il componente deve consentire la gestione informatizzata delle concessioni delle licenze di pesca e del relativo albo.
4.5.2 Normativa di riferimento
La normativa di riferimento è la seguente:
- la L. R. 4/2006 art. 22 cc. 13-14: recepisce la legge nazionale ed attribuisce alle amministrazioni provinciali la competenza per il rilascio dei patentini di pesca;
- La L. 433/1968, recante “nuove norme in materia di licenze di pesca nelle acque interne”;
- D.A.D.A. n. 412 del 10.03.1995 (pubblicato sul BURAS n.18 del 26.05.1995) “disciplina dell'attività di pesca; periodi di divieto e le taglie minime dei pesci d'acqua dolce”;
- D.A.D.A. n. 641 del 28.04.1997 (pubblicato sul BURAS n. 14 del 2.05.1997) “Integrazione all'elenco degli attrezzi da pesca per le acque interne, disposizioni relative ai quantitativi pesabili e ai periodi di pesca”.
4.5.3 Soggetti coinvolti
Pescatore: Soggetto che richiede il rilascio della licenza di pesca, che può essere:
- pescatore sportivo (cat. B);
- pescatore professionista iscritto all'INPS (cat. A);
- pescatore temporaneo, turista/straniero (cat. D);
Provincia: ente responsabile dell'istruzione della pratica e titolare del rilascio della licenza per le patenti B e D;
Servizio Pesca dell'Assessorato Agricoltura: ente detentore e gestore dell’albo delle licenze di pesca e responsabile per il rilascio dei patentini di tipo A.
4.5.4 Requisiti funzionali
Il processo di gestione delle domande di licenza di pesca nelle acque interne, da automatizzare con l’applicativo web, è il seguente:
Domanda di licenza patentini di pesca di tipo A
1. Il pescatore presenta domanda di licenza di pesca di tipo A;
2. il servizio pesca dell'Assessorato regionale dell’agricoltura avvia il procedimento per il rilascio della licenza:
- effettua i controlli in loco, la presenza degli allegati alla domanda (eventuali verifiche del numero di iscrizione INPS verrà fatto a campione in seguito);
- verifica se ci sono vincoli o regolamentazioni;
- verifica se esistono dei patentini duplicati in corso di validità; in caso positivo, procede alla disattivazione del precedente
- se le verifiche effettuate danno esito positivo, emette il patentino:
a. una copia è rilasciata al pescatore richiedente;in caso positivo, procede alla disattivazione del precedente;
b. la copia cartacea della domanda viene mantenuta dal servizio pesca
Domanda di licenza patentini di pesca di tipo B e D
1. Il pescatore presenta domanda di licenza di pesca di tipo B e D;
2. La Provincia avvia il procedimento per il rilascio della licenza:
- effettua i controlli in loco, e verifica la presenza degli allegati alla domanda;
- verifica se ci sono vincoli o regolamentazioni imposte dal servizio Pesca (appositi sistemi di allerta avviseranno l'eventuale esubero);
- verifica se esistono dei patentini duplicati in corso di validità; in caso positivo, procede alla disattivazione del precedente;
- se le verifiche effettuate danno esito positivo, emette il patentino:
- una copia è rilasciata al pescatore richiedente;
- la copia cartacea della domanda viene mantenuta dall'ente istruttore.
Altre funzionalità
L'applicativo deve poter produrre la stampa di un documento cartaceo, su cui applicare la marca da bollo, e del tesserino di pesca.
La gestione dell’albo delle licenze comprende inoltre:
- Controllo degli esuberi nell'emissione nelle varie province;
- Esportazione e importazione di flussi contabili;
- Esportazione dei numeri INPS per un eventuale controllo incrociato;
- Possibilità di esportazione dati (per altre banche dati, per siti istituzionali);
- Possibilità di creazione di account per enti esterni (per consultazione/report);
- Visione scadenze delle licenze;
- Controllo dei duplicati;
- Revoca della validità delle licenze.
- Impostazione e gestione delle soglie di allerta per la regolamentazione delle richieste di licenza nel periodo di tempo indicato.
4.5.5 Dimensionamento
Di seguito si indicano i volumi da gestire:
- 2.000 licenze di tipo B registrate all'anno;
- 8.000 licenze di tipo B attive (in 5 anni);
- 500 licenze di tipo A registrate all'anno.
4.6 Componente “Albo degli operatori agrituristici”
4.6.1 Obiettivi
Il componente deve consentire la gestione informatizzata dell’albo degli operatori agrituristici.
4.6.2 Normativa di riferimento
- La L. 96/2006, “Disciplina dell’agriturismo”, e la precedente L. 730/1985: definiscono l’attività agrituristica, impongono i criteri e i limiti da seguire e forniscono tutte le direttive necessarie per la creazione, l’amministrazione e la gestione dell’attività.
- la L. R. 18/1998: recepisce la legge nazionale ed introduce alcune direttive peculiari per la Sardegna, soprattutto sui tempi e modi di presentazione della domanda di abilitazione e sulla tipologia di servizi che l’azienda agrituristica può e deve offrire.
4.6.3 Soggetti coinvolti
Azienda: richiede il rilascio del “Certificato di Operatore Agrituristico”.
Comuni: ente responsabile del rilascio dell’autorizzazione all’esercizio dell’attività agrituristica.
Assessorato dell’Agricoltura: ente detentore e gestore dell’albo degli operatori agrituristici.
Xxxxxxx XXXXX Sardegna: ente incaricato al controllo dei requisiti dichiarati dai richiedenti nella relazione tecnica.
ASL: ente incaricato al controllo del rispetto dei requisiti igienico-sanitari.
ISTAT e Guardia di Finanza: accesso in consultazione delle statistiche elaborate sui dati dell’albo.
4.6.4 Requisiti funzionali
Il processo di gestione del patentino dell’albo degli operatori agrituristici, da automatizzare con l’applicativo web, è il seguente:
Procedura di iscrizione all'Albo
1. L’azienda, che intende intraprendere attività agrituristica, presenta al proprio Comune la
domanda di autorizzazione all’esercizio dell’attività agrituristica;
2. Il Comune avvia il procedimento per il rilascio dell’autorizzazione all’esercizio dell’attività agrituristica ed esegue i seguenti passaggi:
− effettua i controlli in loco, avvalendosi degli uffici periferici dell’agenzia LAORE e dell’ASL di competenza;
− se le verifiche effettuate danno esito positivo, emette un certificato di operatore agrituristico in duplice copia e la consegna all'azienda richiedente;
3. l’azienda presenta domanda di iscrizione all’Assessorato allegando la documentazione prevista e il certificato di operatore agrituristico rilasciato dal comune;
4. l’Assessorato dell’Agricoltura acquisisce la domanda di iscrizione all’albo e avvia l’istruttoria:
a. se l’istruttoria si conclude con esito positivo, l’azienda è iscritta all’albo e riceve l’attestato di iscrizione;
b. se l’istruttoria si conclude con esito negativo, all’azienda è notificato il risultato dell’istruttoria con le relative motivazioni;
c. in fase istruttoria può essere richiesta all’azienda documentazione integrativa e il procedimento resta sospeso sino al suo ricevimento.
Procedura di cancellazione dall'Albo
1. L’azienda, che intende interrompere l’attività agrituristica, presenta la domanda di cancellazione dall'albo;
2. l'Assessorato procede alla cancellazione dall'albo.
Altre funzionalità richieste all’applicativo:
La gestione dell’albo comprende inoltre:
- le volture dell’attestazione rilasciata dalla Regione da una azienda ad un’altra;
- la produzione in formato pdf della reportistica e della documentazione del procedimento: il certificato, l’attestato d’iscrizione, la richiesta d’integrazione della documentazione, etc.;
- l’elaborazione di semplici report statistici;
- la gestione delle comunicazioni con i Comuni e con gli altri enti coinvolti nel procedimento con tracciamento della corrispondenza;
- La progettazione dell’albo degli operatori agrituristici dovrà integrarsi all’interno del portale SIAR. Trattando dati relativi ad aziende agrituristiche, il nuovo applicativo si appoggerà all’Anagrafe Regionale delle Aziende Agricole.
4.6.5 Dimensionamento
Di seguito si indicano i volumi da gestire:
- 1.100 aziende iscritte all’albo, di cui 725 attive;
- 85 domande d’iscrizione all’albo, presentate nel 2007;
- 22 domande di cancellazione dall’albo, presentate nel 2007.
4.7 Componente “Catalogo Prodotti”
4.7.1 Obiettivi
Il componente deve consentire la gestione informatizzata del Catalogo dei prodotti agricoli e alimentari con il fine di valorizzare le produzioni regionali, anche a Denominazione di Origine Protetta (DOP), attraverso l’implementazione di funzionalità che possano sottolineare il radicamento di tali produzioni sul territorio, attivando, contestualmente alla valorizzazione del prodotto in quanto tale, il valore sinergico del legame con il paesaggio circostante.
4.7.2 Normativa di riferimento
- Reg. CE 510/2006, relativo alla protezione delle indicazioni geografiche e delle denominazioni d’origine dei prodotti agricoli e alimentari;
- D.M. del 21/5//2007, Procedura a livello nazionale per la registrazione delle DOP e IGP, ai sensi del regolamento (CE) n. 510/2006;
- D. L. 173/1998, art. 8 “Valorizzazione del patrimonio gastronomico” per i prodotti tradizionali;
- D. M. 350/1999, per l’individuazione dei prodotti tradizioni di cui all’art.8 del D. L. 173/1998.
- Reg. CE 1698/2005, sul sostegno allo sviluppo rurale da parte del Fondo europeo agricolo per lo sviluppo rurale (FEASR);
- Reg. CE 1974/2006, recante disposizioni di applicazione del regolamento (CE) n. 1698/2005 del Consiglio;
- Reg. CE 2092/1991, relativo ai prodotti destinati al consumo umano ottenuti e certificati applicando il metodo dell’agricoltura biologica;
- Reg. CE 1493/1999 (Titolo VI), relativo ai vini qualificati VQPRD;
- Reg. CE 110/2008, relativo alla definizione, alla designazione, alla presentazione, all’etichettatura e alla protezione delle indicazioni geografiche delle bevande spiritose e che abroga il regolamento (CEE) n. 1576/89;
- Reg. CE 2200/96, relativo all’organizzazione comune dei mercati nel settore degli ortofrutticoli;
- Reg. CE 1182/2007, relativo all’OCM Ortofrutta - Organizzazioni dei Produttori;
- Reg.CE applicativo 1580/2007, recante modalità di applicazione dei regolamenti (CE) n.
2200/96, (CE) n. 2201/96 e (CE) n. 1182/2007 nel settore degli ortofrutticoli;
- Reg. CEE 2081/92 relativo alla protezione delle indicazioni geografiche e delle denominazioni d'origine dei prodotti agricoli ed alimentari;
- D.Lgs.102/2005, Regolazione dei mercati agroalimentari;
- D.M. 85/2007;
- D.G.R. 27/16 del 17 luglio 2007 e succ. modifiche.
4.7.3 Soggetti coinvolti
- Assessorato dell’Agricoltura: gestisce la parte amministrativa del Catalogo, tiene aggiornate le news e la normativa di riferimento. Ha il compito di validare le informazioni inserite dagli altri attori per renderle pubblicabili.
- Servizio Politiche di Mercato e Qualità: Svolge funzioni relative al riconoscimento e alla promozione delle organizzazioni dei produttori e delle loro associazioni, ai marchi, alle denominazioni e ai consorzi di tutela;
- Servizio Produzioni: gestisce il settore vitivinicolo e ortofrutticolo.
- Consorzi di tutela: per statuto hanno il compito di tutelare e promuovere uno specifico prodotto DOP o IGP.
- Gestiscono i dati anagrafici del consorzio e dei soci;
- Danno indicazione sui parametri di quantità e qualità di produzione certificata.
- Organismi di Controllo e Certificazione: hanno il compito di controllare e garantire il pieno rispetto dei Disciplinari di Produzione e che i prodotti recanti un marchio d'origine rispondano a quanto dichiarato. In Sardegna sono Organismi di Controllo l’AGRIS Sardegna e l’OCPA (Organismo controllo produzioni origine animali).
- Gestiscono i dati anagrafici dell’organismo di controllo e dei produttori;
- Gestiscono la modulistica e piani di controllo.
- Organizzazioni dei Produttori (OP): sono la forma associativa riconosciuta a livello comunitario atta a rafforzare il potere contrattuale dei produttori.
- Gestiscono i dati anagrafici dell’OP e dei suoi produttori;
- Gestiscono gli elenchi dei prodotti;
- Consumatori e Produttori: consultano il catalogo e, dove possibile, accedono alle funzioni di tracciabilità delle singole produzioni, anche con l’ausilio della rappresentazione .
- Ministero delle Politiche Agricole Alimentari e Forestali (MIPAF): consulta il catalogo.
4.7.4 Requisiti funzionali
I prodotti agroalimentari censiti nel catalogo rientrano nei seguenti marchi di qualità:
- Marchi di Origine (CE):
− DOP (Denominazione di Origine Protetta): identifica la denominazione di un prodotto la cui produzione, trasformazione ed elaborazione avvengono in un'area geografica determinata.
− IGP (Indicazione Geografica Protetta): identifica la denominazione di un prodotto di cui almeno uno degli stadi della produzione, trasformazione o elaborazione avviene in un'area geografica determinata.
- Marchi di Origine (IT), utilizzati solo per i vini:
− DOC (Denominazione di Origine Controllata): indica vini di qualità originari di zone limitate richiamate nel nome del vino. Le caratteristiche enochimiche (estratto secco, acidità totale, etc.) ed organolettiche (colore, odore, sapore) devono rispettare precisi requisiti fissati dai Disciplinari di produzione.
− DOCG (Denominazione di Origine Controllata e Garantita): indica il particolare pregio qualitativo di alcuni vini DOC di notorietà nazionale ed internazionale. Per la certificazione DOCG sono richiesti requisiti tra i quali l'imbottigliamento nella zona di produzione e in recipienti di capacità inferiore a cinque litri.
− IGT (indicazione Geografica Tipica): indica vini da tavola di qualità prodotti in aree generalmente ampie. I requisiti sono meno restrittivi di quelli richiesti per i vini DOC.
- Marchio Agricoltura biologica: è un marchio regolato dal Reg. CE 2092/91. Può essere apposto volontariamente dai produttori di prodotti sottoposti a un controllo e risultati composti da ingredienti di cui almeno il 95% ottenuti con il metodo biologico.
- Marchio Prodotti tradizionali: è un marchio di proprietà del Mipaf che si colloca al di fuori della normativa sulle attestazioni DOP, IGP e STG.
Inoltre sono presenti anche prodotti in corso di riconoscimento, per i quali è possibile visionare informazioni rilevanti come la situazione dell’iter di approvazione e i produttori che hanno avanzato la proposta.
Il catalogo dovrà consentire:
- La gestione dei marchi di qualità esistenti, con relativi disciplinari e riferimenti normativi;
- L’inserimento dei prodotti, con l’indicazione di tutte le informazioni che li caratterizzano, anche in base al marchio di qualità che possiedono;
- La ricerca dei prodotti presenti nel Catalogo, in base ad una serie di parametri, e successiva visualizzazione del dettaglio della scheda del prodotto selezionato;
- La modifica e la cancellazione dei prodotti;
- La gestione dello storico dei prodotti;
- La tracciabilità dell’iter di riconoscimento del marchio di qualità di un prodotto.
Gestione informazioni generali
L’Assessorato avrà la possibilità di gestire una sezione generale contenente ad esempio:
- News e segnalazione di eventi, con gestione archivio;
- Collegamenti all’informativa a livello comunitario, italiano e regionale.
Gestione anagrafica Consorzi di Tutela
- Gestione informazioni anagrafiche Consorzio;
- Gestione elenco soci del Consorzio;
- Gestione vincoli di produzione certificata, quantità e qualità;
- Gestione sezione informazioni aggiuntive, news, modulistica, normativa e riferimento al sito del Consorzio.
Gestione anagrafica Organismi di Controllo
- Gestione informazioni anagrafiche Organismo di Controllo;
- Gestione elenco produttori controllati dall’Organismo di Controllo;
- Gestione piano di controllo;
- Gestione sezione informazioni aggiuntive, news, modulistica, normativa e riferimento al sito dell’Organismo di Controllo.
Processo di validazione delle informazioni
Al fine di renderle pubblicabili, l’Assessorato dovrà validare le informazioni inserite dagli enti esterni nelle anagrafiche a corollario del Catalogo operando una:
- validazione dati e informazioni inserite dai Consorzi di Tutela;
- validazione dati e informazioni inserite dagli Organismi di Controllo;
- validazione dati e informazioni inserite dalle Organizzazioni dei Produttori.
Prima della validazione, tali dati rimarranno in uno stato di bozza e diventeranno pubblici solo dopo la validazione.
Funzionalità aggiuntive
E’ necessario prevedere, come funzionalità del Catalogo, anche le seguenti:
- La gestione di reportistica, statistiche, elenchi, etc.;
- La gestione della localizzazione geografica dei prodotti a marchio di Origine; attraverso il codice di tracciabilità di un prodotto, il sistema visualizzerà, all’interno di uno scenario tridimensionale interattivo, le informazioni relative all’azienda produttrice. L’ambiente tridimensionale sarà costituito dal navigatore Italia3D.
4.7.5 Dimensionamento
Di seguito si indicano i volumi da gestire:
- Alcune centinaia di schede prodotto;
- 5 Consorzi di Tutela e 1 Consorzio per il prodotto in Protezione Transitoria;
- 7 Organizzazioni di Produttori del settore ortofrutta;
- 15 Organizzazioni di Produttori del settore non ortofrutta;
- Circa 70 aziende iscritte all’albo degli oliveti DOP.
5 Vincoli
5.1 Vincoli tecnologici
Le componenti da realizzare dovranno integrarsi all’interno dei portali web della Regione Autonoma della Sardegna, in particolare nell’area tematica dedicata all’Agricoltura, pertanto, nella fase di progettazione e sviluppo dovranno essere rispettate le seguenti specifiche:
- la presentazione dei contenuti sarà gestita autonomamente dal presentation tier regionale. Il colloquio con tale livello dovrà avvenire attraverso la produzione da parte delle componenti applicative oggetto della commessa di un flusso dati in formato XML correttamente formattato secondo le specifiche indicate dal committente (cfr Allegati – XML PRES TIER);
- gli applicativi dovranno utilizzare esclusivamente il sistema di autenticazione e autorizzazione già in uso nel sistema SIAR (cfr Allegati – AuthSIAR);
- per la visualizzazione dei contenuti cartografici in ambiente web deve utilizzare le librerie OpenLayers in linguaggio JavaScript; per la documentazione al riguardo si veda xxxx://xxxx.xxxxxxxxxx.xxx/xxxx/Xxxxxxxxxxxxx . Eventuali ulteriori indicazioni sul tema saranno fornite in corso d’opera;
- Sviluppo basato su tecnologia Java 2 Enterprise Edition (J2EE) e application server BEA WebLogic Server 8.1 SP6 o in alternativa Apache Tomcat 6.x;
- Piattaforma RDBMS Oracle 10g;
- La produzione della reportistica e delle stampe dovrà avvenire con un flusso dati in formato XML con modalità analoghe al punto 1;
- Adozione di un framework MVC-Compliant J2EE standard, da concordare in corso d'opera;
- Rispetto del processo di segnalazione multi-livello dei messaggi di sistema (logging e audit), coerentemente con il modello da concordare in corso d'opera;
- Utilizzo del tool di build Apache ANT.
5.2 Vincoli normativi
Gli applicativi dovranno rispettare la normativa in vigore al momento del rilascio. Pertanto l’Amministrazione si riserva la possibilità di apportare modifiche alle specifiche indicate per adeguarsi a eventuali modifiche normative.
5.3 Vincoli organizzativi
Tutte le attività previste dovranno essere svolte sotto la supervisione e coordinamento del personale incaricato da Sardegna IT.
6 Modalità di realizzazione
La seguente tabella delinea le attività e gli output:
Attività | Output |
Raccolta e analisi dei requisiti | Documento dei requisiti e specifiche funzionali Documenti dei test di accettazione |
Progettazione tecnica | Documenti di disegno tecnico dell'architettura Piano dei test Piano dei deploy Piano di collaudo |
Sviluppo | Codice sorgente dei componenti software Suite di test unitari per ogni modulo Documentazione utente Verbali di rilascio |
Integrazione | Script di creazione e popolamento banche dati Componenti software integrati Rapporti di esecuzione dei test di integrazione e di sistema Documenti di deploy |
Collaudo | Rapporti di esecuzione dei test di accettazione Documento di rilascio al collaudo |
Formazione | Piano di formazione Rapporti di formazione |
Manutenzione correttiva | Documento di analisi della soluzione Codice sorgente corretto (patch) Rapporti di esecuzione dei test Adeguamento della documentazione e della manualistica |
In particolare si sottolinea che:
- tutta la documentazione dovrà essere predisposta sulla base di modelli concordati in corso d’opera;
- i documenti di progettazione dovranno essere redatti facendo uso della notazione formale UML 2.0;
- il codice sorgente dovrà:
- rispettare le code convention Java definite dalla Sun Microsystems;
- essere “auto-documentante” secondo lo standard Javadoc;
- ogni componente sviluppato dovrà essere corredato di una adeguata suite di test unitari, realizzate con JUnit;
- tutti gli script e le procedure PL/SQL di creazione, aggiornamento e popolamento delle banche dati dovranno essere adeguatamente commentati e documentati.
La proprietà del software e di tutto quanto prodotto nel contesto del progetto è di proprietà dell’Amministrazione regionale.
Sardegna IT, per conto dell’Amministrazione Regionale, si riserva il diritto di affiancare proprio personale al personale della società affidatario nelle fasi di esecuzione della fornitura al fine di acquisire le competenze per la gestione degli applicativi nelle fasi successive al completamento della fornitura.
Il rilascio di ogni deliverable previsto sarà oggetto di un processo formale di approvazione e accettazione da parte di Sardegna IT che determinerà la possibilità di passare alla fase successiva.
6.1 Raccolta e analisi dei requisiti
6.1.1 Obiettivi
L’obiettivo della raccolta dei requisiti e della fase di analisi è quella di portare alla comprensione del dominio del problema e dei bisogni dell’amministrazione in termini di funzionalità richieste, performance, collaborazione con sistemi già in essere e tutto ciò che riguarda le caratteristiche dell’applicazione.
In questa fase verrà definito il modello di esecuzione del processo, la tempistica e modalità di rilascio dei moduli previsti.
6.1.2 Deliverables
Documento dei requisiti e specifiche funzionali
Il documento di specifiche deve contenere l'elencazione formale e relativa descrizione di tutti requisiti dell'applicazione, siano essi funzionali che qualitativi, emersi nella fase di definizione delle esigenze dell’utente. I requisiti devono essere univocamente identificabili ed eventualmente relazionati tra loro in scala gerarchica o tramite riferimenti incrociati.
In particolare, deve contenere:
- descrizione delle esigenze
- definizione delle interfacce esterne
- definizione dei requisiti funzionali e non
- definizione del contesto attuale
- vincoli di progetto
- numero e tipologia degli utenti coinvolti
- indicazioni sull’architettura
- dati trattati, in forma di schema concettuale iniziale, nonché stima iniziale dei volumi
- riferimenti a ulteriore documentazione di interesse prodotta o preesistente
- prestazioni
Documenti dei test di accettazione
I test di accettazione devono verificare che l’applicativo risponda alle specifiche dichiarate nei documenti di riferimento e il risultato della loro esecuzione determinerà la conformità della fornitura del prodotto software.
La validazione e la conseguente accettazione del prodotto software è subordinata al superamento dell'intero pacchetto dei test definiti nel piano.
In particolare deve essere documentato:
- L’individuazione del flusso informativo del sistema ed in particolare la checklist di validazione
- Dovranno essere formalizzati i metodi manuali ed automatici da utilizzarsi durante la fase di test
- Dovrà essere specificato l’ambiente di test comprensivo di infrastruttura HW/SW prendendo in considerazione eventuali moduli di terze parti facenti parte della soluzione.
6.2 Progettazione tecnica
6.2.1 Obiettivi
La progettazione deve fornire il dettaglio della soluzione proposta in un adeguato formalismo che consenta una efficace comprensione dell’infrastruttura sia a livello di sistema sia a livello di singolo modulo.
Nella soluzione progettuale deve essere garantita la rintracciabilità dei requisiti e la coerenza con i requisiti tra i componenti e le unità software, la fattibilità della realizzazione, della gestione operativa e della manutenzione.
È parte integrante del processo di progettazione la definizione dei test interni (test unitari, test funzionali, test di integrazione, test di sistema) come formalizzate nel Piano di test.
Durante la stesura della progettazione dovrà essere presa ogni precauzione affinché l'applicazione garantisca un adeguato livello di sicurezza applicativa, secondo le linee guida promosse dalla “community” OWASP, al fine di escludere o perlomeno arginare i più noti attacchi informatici. L'applicazione dovrà garantire particolare attenzione alla protezione di eventuali dati sensibili.
6.2.2 Deliverables
Documenti di disegno tecnico dell'architettura
Il documento di disegno tecnico deve definire:
- disegno concettuale del sistema;
- architettura applicativa dei componenti e gli elementi software;
- dettaglio per ciascun elemento delle componenti ad alto livello e le relative unità (moduli applicativi);
- interfacce e comunicazione tra i vari moduli interni;
- interfacce e modalità di comunicazione con i moduli esterni;
- disegno logico e fisico della Base Dati;
- tecnologia di sviluppo da adottare.
Piano dei test
L'obiettivo generale dei test è quello di verificare che i prodotti software raggiungano un adeguato livello di qualità, tale da soddisfare le aspettative del cliente. Il piano dei test indica gli obiettivi e la strategia che sarà applicata durante l’attività di testing e verifica.
Il documento deve illustrare la metodologia di test adottata in termini di fasi e documenti prodotti e descrivere gli strumenti di supporto utilizzati.
Il documento formalizza, oltre ai casi di test, anche l’ambiente e le risorse necessarie per la loro esecuzione e le modalità di gestione delle anomalie.
Il piano dei test ha lo scopo di definire tramite quale tipologia di test verranno sottoposti a verifica i prodotti oggetto di consegna per superare la fase di validazione rispetto ai requisiti dell'utente.
In particolare, il piano di test deve contenere:
- indicazioni sulla strategia, la metodologia e gli obiettivi dei test;
- la loro pianificazione temporale;
- la pianificazione delle risorse necessarie all'esecuzione dei test (prodotti, ambienti operativi, risorse umane, etc.);
- l'elencazione dei test non funzionali, tendenti a verificare requisiti qualitativi del prodotto;
- l'elencazione dei test funzionali del prodotto;
- la mappatura dei test pianificati con i requisiti;
- il livello di copertura atteso.
Specifiche di test
Il documento deve integrare il Piano di Test e deve contenere:
- Modalità di generazione delle basi dati di test;
- Condizioni particolari da aggiungere alle basi dati di test;
- Dimensioni stimate delle basi dati di test;
- Oggetti da sottoporre a test:
- Codice;
- Documentazione;
- Eventuali prodotti intermedi.
- per ogni test funzionale, non funzionale:
- Descrizione delle condizioni di test previste;
- Setup delle condizioni iniziali (manuali ed automatiche);
- Valori di input;
- Valori attesi;
- Condizioni di ripetibilità;
- Copertura dei test.
Piano dei deploy
Il documento indica le modalità di deploy dell’applicazione all’interno dell’ambiente di collaudo e di produzione.
Dovranno essere fornite tutte le indicazioni per l’installazione la configurazione e il controllo dell’applicazione ed eventuali moduli esterni all’applicativo necessari per il suo corretto funzionamento, come indicato dal documento di specifica dei requisiti.
Le modalità effettive di deploy verranno concordate in corso d’opera con l’amministrazione.
Piano di collaudo
Il Piano di Collaudo costituisce la guida per lo svolgimento delle attività di collaudo dell’applicazione realizzata.
Nel corso di tale attività il Fornitore deve specificare le operazioni di verifica che potranno essere effettuate dall’Amministrazione per eseguire il collaudo della fornitura. Nella descrizione delle prove di collaudo deve essere garantita la rintracciabilità dei requisiti indicati nei documenti contrattuali e nella Specifica dei Requisiti e la coerenza con i requisiti stessi. Il risultato dell’attività è costituito dalla Specifica di collaudo, ovvero da un documento o insieme di documenti che potranno essere utilizzati a titolo di guida dalla Commissione di collaudo per eseguire il collaudo della fornitura.
Il documento, che potrà essere derivato dal piano di test, dovrà contenere almeno le seguenti informazioni:
- Strategia, metodologia e obiettivi;
- Caratteristiche dell’hardware e del software di base previste;
- Descrizione dei test formali, funzionali, non funzionali da eseguire.
6.3 Sviluppo
6.3.1 Obiettivi
In questa fase il fornitore sviluppa le componenti software previste secondo le specifiche progettuali approvate procedendo alla codifica del software, documentazione dei moduli e la realizzazione delle banche dati.
6.3.2 Deliverables
Codice sorgente dei componenti software
- Deve rispettare le code convention stabilite dalla Sun Microsystems
- Deve essere auto-documentante secondo lo standard Javadoc
- Deve rispettare le specifiche progettuali approvate o modificate in corso d’opera
- Deve avere a corredo gli script Apache ANT per la compilazione dell’applicazione.
Suite di test unitari per ogni modulo
- Ogni singolo modulo avrà a corredo l’apposita suite di test unitari
Documentazione utente
- Manuale utente in formato elettronico relativa a tutte le funzionalità previste
- Manuale di gestione necessario alle strutture preposte all’installazione ed esercizio delle componenti realizzate
Verbali di rilascio
Dovranno essere forniti i seguenti verbali di consegna e rilascio relativi al codice sorgente, documentazione e banche dati relative alle componenti:
- Modulo per la gestione del rilascio dei Patentini Xxxxx
- Modulo per la gestione del Registro informatico debitori
- Modulo per la gestione dell’albo IAP
- Modulo per la gestione dell’Albo delle Licenze di pesca
- Modulo per la gestione dell’Albo degli operatori agrituristici
- Modulo per la gestione del Catalogo dei Prodotti agro-alimentari.
6.4 Integrazione
6.4.1 Obiettivi
In questa fase i componenti sviluppati e testati vengono integrate all’interno dell’architettura del SIAR, le banche dati sono popolate come previsto dai requisiti funzionali.
Il sistema deve quindi essere sottoposto ad un test d’integrazione volto a verificare la perfetta funzionalità dei componenti e la loro corretta cooperazione ed un test di sicurezza il cui scopo è quello di verificare il livello di protezione dell'applicazione.
6.4.2 Deliverables
I deliverables di questa fase sono costituiti da:
- Script di creazione e popolamento banche dati
- Componenti software integrati
- Rapporti di esecuzione dei test di integrazione, di sistema e di sicurezza
- Documenti di deploy
6.5 Collaudo
L’attività è eseguita da una Commissione di collaudo nominata da Sardegna IT ed individuata, nella sua composizione, sulla base delle capacità professionali e di giudizio richieste. La Commissione opera con autonoma responsabilità e secondo le prescrizioni della normativa di riferimento ed ha il compito di verificare che quanto realizzato dal Fornitore sia conforme ai requisiti indicati nel presente Disciplinare tecnico e nei documenti di progetto. Le prove di collaudo sono di regola eseguite nell’ambiente di collaudo secondo quanto specificato nel processo di Progettazione.
Il Fornitore deve supportare la Commissione nella esecuzione delle prove, nel rilevamento dei risultati, nella stesura del rapporto finale. Per svolgere le prove di collaudo la Commissione può utilizzare, a titolo di guida, la Specifica di collaudo predisposte dal Fornitore nell’ambito del processo di Progettazione, e può prendere visione dei risultati dei test interni eseguiti dal Fornitore nel corso del processo di Realizzazione e di ogni registrazione concernente le attività di riesame, verifica e validazione svolta.
La verifica con esito positivo della fornitura termina con l’emissione di un verbale di collaudo positivo, che sancisce la conformità ai requisiti contrattuali del prodotto software e/o l’erogabilità del servizio oggetto di fornitura. L’accettazione da parte dell’Amministrazione dell’esito positivo del collaudo, dà luogo all’accettazione della fornitura. In caso di esito negativo del collaudo e/o di non-conformità rispetto ai requisiti contrattuali, il Fornitore, in accordo con il processo di Risoluzione dei problemi, è tenuto a rimuovere le non conformità ed a risolvere le malfunzioni e a presentare nuovamente la fornitura al collaudo, nei tempi e nei modi stabiliti nel contratto. La conclusione del collaudo con esito positivo e l’accettazione da parte dell’Amministrazione della fornitura, comportano il congelamento della configurazione di base del prodotto software e/o del sistema che ospita l’ambiente di erogazione del servizio.
6.5.1 Deliverables
- Rapporti di esecuzione dei test di accettazione
- Documento di rilascio al collaudo
6.6 Formazione
E’ necessario prevedere l’erogazione di attività di formazione ed affiancamento per gli operatori coinvolti da svolgersi in collaborazione con il personale incaricato da Sardegna IT. Di seguito si determina la stima delle attività formative richieste per ciascun componente:
Modulo | Contenuti | Destinatari | Sessioni |
Xxxxxxxx patentini verdi | Presentazione modulo applicativo ed affiancamento | Personale province: circa 20 persone Personale LAORE e Assessorato: circa 20 persone | 3 sessioni di 1 giornata distribuite nel territorio regionale |
Archivio debitori | Presentazione modulo applicativo ed affiancamento | Personale ARGEA: circa 20 persone Personale Assessorato: circa 15 persone | 3 sessioni di 1 giornata distribuite nel territorio regionale |
Albo IAP | Presentazione modulo applicativo ed affiancamento | Personale province: circa 20 persone Personale Argea e Assessorato: circa 10 persone | 3 sessioni di 1 giornata distribuite nel territorio regionale |
Albo Licenze di Pesca | Presentazione modulo applicativo ed affiancamento | Personale province: circa 20 persone Personale Assessorato: circa 5 persone | 3 sessioni di 1 giornata distribuite nel territorio regionale |
Albo Operatori Agrituristici | Presentazione modulo applicativo ed affiancamento | Personale comuni: circa 400 persone Personale Assessorato: circa 15 persone | 8 sessioni su base provinciale di 1 giornata + 1 giornata per il personale dell’Assessorato |
Catalogo prodotti agroalimentari | Presentazione modulo applicativo ed affiancamento | Personale Assessorato: circa 15 persone Personale OP, Consorzi e altri organismi: circa 50 persone | 3 sessioni di 1 giornata distribuite nel territorio regionale |
In particolare si sottolinea che:
- Gli interventi formativi dovranno avvenire presso le sedi individuate e messe a disposizione dall’Amministrazione nel territorio regionale;
- Il fornitore dovrà fornire agli allievi tutto il materiale (cartaceo e/o elettronico) che rimarrà di proprietà dell’Amministrazione;
- Il fornitore dovrà far compilare e firmare agli allievi i moduli di presenza e le schede di valutazione dell’intervento formativo e il Rapporto dell’attività di formazione. Le schede compilate e il Rapporto dovranno essere inviate all’Amministrazione entro 1 settimana dalla conclusione dell’intervento formativo.
6.6.1 Deliverables
Piano di formazione
Il piano di formazione dovrà descrivere il programma dei singoli moduli formativi, le modalità di erogazione, la pianificazione prevista.
Rapporti di formazione
Al termine di ogni evento formativo dovrà essere sottoscritto un rapporto di formazione che contenga le seguenti informazioni minime:
- Ora, data e luogo;
- Partecipanti;
- Argomenti trattati
Tale rapporto dovrà essere controfirmato dai partecipanti alla formazione. Nel caso di eventi formativi che coinvolgono un gran numero di persone il rapporto può essere controfirmato dal personale indicato dall’Amministrazione.
6.7 Manutenzione correttiva
6.7.1 Obiettivi
Successivamente all’accettazione della Fornitura è previsto un servizio di manutenzione correttiva al fine di correggere eventuali malfunzionamenti del riscontrati sui componenti oggetto della fornitura entro 12 mesi solari consecutivi dalla data di collaudo.
6.7.2 Deliverables
Dovranno essere prodotti in questa fase i seguenti documenti:
- Documenti di analisi e progettazione della soluzione attestante le motivazioni e le modalità intraprese per la risoluzione dei problemi riscontrati in esercizio;
- Codice sorgente relativo alla correzione effettuata secondo le già esposte modalità di realizzazione (code conventions, documentazione, etc.);
- Rapporti di esecuzione dei test, sia unitari per i moduli interessati sia di funzionalità, integrazione e non regressione per tutte le aree coinvolte;
- Adeguamento della documentazione e della manualistica se la modifica comporta variazioni a livello funzionale o di presentazione.
7 Modalità di esecuzione
7.1 Gestione del progetto
7.1.1 Piano di Progetto
Il Fornitore dovrà predisporre un Piano di progetto relativo a tutte le attività previste dal rapporto contrattuale, indicando per ciascuna attività i tempi, le risorse necessarie ed il relativo impegno. Il Piano di progetto, approvato dal Committente, autorizzerà il Fornitore a dare avvio alle attività.
Il Fornitore in particolare dovrà produrre:
1. un primo Piano di progetto in sede di presentazione dell’Offerta tecnica, che dia evidenza di come intenda organizzare le proprie strutture per eseguire la fornitura richiesta, di quali risorse saranno assegnate, con indicazione dei relativi profili professionali e dei relativi ruoli/responsabilità, di quali strumenti e metodologie saranno utilizzati in caso di aggiudicazione della commessa;
2. una versione aggiornata del Piano di progetto, da consegnare al Committente entro dieci giorni dalla sottoscrizione del contratto che dovrà recepire le indicazioni dell’Amministrazione in merito alle priorità realizzative dei diversi componenti previsti.
Il Piano di progetto deve essere suddiviso in attività e accompagnato da un crono-programma (diagramma di Gantt) che illustri le relazioni temporali e di precedenza delle varie attività.
Per ogni attività deve essere indicato:
- Nome attività;
- Responsabile attività;
- Inizio e Fine;
- Obiettivi;
- Descrizione del lavoro;
- Eventuali sotto-attività;
- Deliverable;
- Milestones.
Il Piano di progetto deve comprende anche una sezione specifica di descrizione delle metodologie usate per la gestione della configurazione e versionamento dei deliverables (codice sorgente, documentazione, etc.) e le procedure utilizzate per la gestione della qualità del progetto.
7.2 Organizzazione generale del progetto
L’Affidatario nominerà al momento della stipula del contratto il capo progetto e impiegherà nella realizzazione dell’appalto personale qualificato così come previsto dall’Offerta Tecnica presentata.
8 Tempi di realizzazione
I lavori dovranno concludersi entro il termine perentorio di 120 giorni solari consecutivi dalla data di stipula del contratto e comunque non oltre la data del 1 dicembre 2008. Il Fornitore dovrà proporre un cronogramma per ciascuna componente da realizzare, da formulare in funzione della metodologia di processo di sviluppo che sarà adottata e con l’evidenza dei tempi di rilascio dei deliverable richiesti. L’insieme dei singoli cronoprogrammi sarà sottoposto alla validazione da parte dell’Amministrazione che indicherà anche la priorità di realizzazione delle componenti richieste, che determineranno la struttura del cronoprogramma complessivo della fornitura.
9 Allegati
- Allegato A - Specifiche sistema di autenticazione – AuthSIAR
- Allegato B - Specifiche interfacciamento presentation tier regionale– XML PRES TIER