L’idea di realizzare una nuova procedura di classificazione tipologica delle aziende agricole nasce dall’esigenza non solo di adeguare il software di classificazione in uso alle disposizioni introdotte dalla nuova metodologia di classificazione comunitaria descritta nei capitoli precedenti, ma anche di rispondere in modo semplice ed efficiente alle richieste provenienti dai diversi soggetti che gestiscono e che collaborano a vario titolo con la rete RICA Italiana.

L’INEA in questi ultimi anni, in concomitanza con il rilascio della nuova metodologia contabile RICA-INEA (GAIA) e la riorganizzazione operativa e gestionale della rete, ha avviato la progettazione e lo sviluppo di nuove metodologie e procedure a supporto non solo delle attività di rilevazione dell’indagine RICA. Sono cresciute infatti le richieste da parte degli operatori del comparto agricolo, di servizi e prodotti che consentissero loro di valutare con maggiore precisione l’evoluzione del sistema agricolo ai diversi livelli (aziendale, settoriale, territoriale, ecc.).

L’INEA infatti, per sua tradizione storica, è impegnata non solo nell’organizzazione e gestione della rete RICA in Italia, ma ha da sempre sviluppato metodologie e procedure rese disponibili anche agli utenti esterni alla rete RICA, in particolare agli agricoltori e ai centri di servizi e sviluppo agricolo regionali. Il pacchetto “Pegaso”, diffuso dall’INEA negli anni ’90, è stato un prodotto INEA molto apprezzato dai tecnici che operavano nel mondo dell’assistenza tecnica agli agricoltori.

La procedura di classificazione, quindi anche questa versione di Class.CE, è un componente del “Pacchetto RICA” offerto dall’INEA alle Regioni e ad altri Enti locali nell’ambito del processo di riorganizzazione della Indagine RICA in Italia, concordato con il Ministero dell’agricoltura (Mipaaf).

L’analisi preliminare, predisposta da uno specifico gruppo di lavoro dell’INEA coordinato dalla sede regionale di Torino, ha consentito di realizzare un sistema che include alcune caratteristiche sviluppate negli anni precedenti con la versione MS Access di CLASS_CE, a cui sono state aggiunte le necessarie modifiche di adattamento al nuovo ambiente di sviluppo, soprattutto tenendo conto delle diverse funzionalità aggiuntive ideate e progettate per la versione descritta in questa guida1.

La scelta è andata verso una applicazione in ambiente internet (web-based), utilizzando strumenti open source sia dal lato database sia per l’implementazione dell’interfaccia utente. Questa soluzione presenta molti vantaggi, il primo dei quali è la completa indipendenza della procedura dal sistema operativo e dal tipo di hardware: non occorre installare alcuna applicazione sul proprio computer, in quanto è sufficiente la presenza di un browser aggiornato per navigare in internet.

La fase di implementazione è stata affiancata da una intensa attività di verifica e collaudo sulle singole parti dell’applicazione. Class.CE è stato progettato con l’obiettivo di realizzare un sistema avente le caratteristiche di usabilità, accuratezza ed efficienza.

Class.CE rappresenta, nell’ambito della gestione delle indagini sulle aziende agricole condotte da INEA, il primo passaggio per individuare, secondo una metodologia ufficiale, le unità da monitorare sia per assolvere ai compiti assegnati all’Istituto dall’Unione Europea e dallo Stato Italiano, sia per definire campioni di aziende agricole da indagare nell’ambito di particolare attività di ricerca e studio.

Class.CE comprende tre strati software diversi. Il livello più alto è rappresentato dall’interfaccia grafica utente (GUI), ed è l’unico livello in cui l’utente può interagire con il sistema. Mentre il livello di servizio costituito dall’ambiente di configurazione e lo strato dati dove vengono memorizzati i dati nel database relazionale, sono invece nascosti all’utente finale.

1 Nella fase di studio della fattibilità del sistema sono state valutate diverse alternative per lo sviluppo, ipotizzando dapprima una possibile trasposizione informatica della procedura realizzata in MS Access; soluzione tecnicamente e funzionalmente non praticabile in relazione non solo all’ambiente di sviluppo, ma anche in considerazione delle funzionalità progettate per la nuova procedura e non previste nel vecchio sistema.