Il sistema applicativo in oggetto fa parte dell’offerta Svimservice di servizi applicativi di rete per la Sanità.

La progettazione di questi servizi applicativi è stata condotta seguendo i workflow e le activity previste dalla metodologia IBM Rational Unified Process®, opportunamente “personalizzata” all’interno del Piano di Qualità. Tra i principi che hanno caratterizzato il processo di sviluppo di questi sistemi applicativi vi sono:

• omogeneità di metodologia, tool e standard di sviluppo
• visione unitaria di tutti i sistemi applicativi, garantita dalla univocità della base dati
• portabilità della soluzione su diversi ambienti operativi target, garantita dall’adozione di standard internazionali “aperti”
• modularità dei singoli sistemi applicativi
• rispetto degli standard di usabilità ed accessibilità
• rispetto delle specifiche tecniche in merito alla cooperazione applicativa, definite dal CNIPA e dal Ministero per l’Innovazione e le Tecnologie

L'omogeneità della metodologia, dei tool e degli standard di progettazione e sviluppo garantisce l'omogeneità dei risultati ottenuti per i diversi servizi applicativi. La progettazione e realizzazione è stata condotta con tecniche object oriented, mediante l’adozione di tool basati su questo paradigma.

L'omogeneità della metodologia è stata garantita non solo con l'utilizzo dello stesso processo di sviluppo e dagli stessi standard, ma anche determinando univocamente l'interpretazione delle tecniche metodologiche per tutti i servizi applicativi dell’offerta e riportandole nei piani di qualità e di documentazione del progetto che hanno guidato l'attività di tutti gli analisti, progettisti e developer.

La visione unitaria dei diversi servizi applicativi è stata garantita sia dalla presenza di figure professionali previste da RUP, che hanno partecipato trasversalmente all’analisi, alla progettazione ed alla realizzazione dei software applicativi di tutte le aree, che dall’utilizzo di un repository comune condiviso da tutte le figure professionali coinvolte. Tra i risultati più macroscopici di queste unitarietà vi è l'unicità del disegno del database. Per cui non è stato progettato un database per ciascun servizio applicativo, ma è stato progettato un database unico su cui ciascun servizio applicativo ha una vista che concorre a definire il suo ambito di automazione. Così sono state eliminate tutte le possibili ridondanze sui dati fra servizi applicativi diversi, con tutti i problemi di inconsistenza e di allineamento che ne sarebbero derivati. Anche dal punto di vista funzionale vi è una notevole omogeneità ed è garantita l'univocità. Sempre in forza del ruolo delle figure professionali citate e delle possibilità offerte dai tool, i servizi sono stati analizzati, progettati e realizzati in maniera uniforme evitando ridondanze di web services.

Alla uniformità degli ambienti di sviluppo si aggiunge l'adozione di standard produttivi che, definiti all’avvio del progetto, hanno consentito di uniformare i comportamenti produttivi e la struttura dei deliverable e dei semilavorati. Ne sono esempi gli standard di nomenclatura degli oggetti della progettazione, gli standard di progettazione della interfaccia utente, gli standard per la progettazione della logica di business e di integrazione, della logica di accesso ai dati e la politica per la gestione ed il controllo degli accessi

Trattandosi di applicazioni sviluppate con tecnologie standard e Java based, le soluzioni garantiscono una portabilità elevata su diverse piattaforme.

Tutta la fase di progettazione è stata svolta in modo da garantire la massima coesione delle componenti software (funzionale) in modo che siano facilmente manutenibili e riusabili. L'elevata coesione delle componenti garantisce inoltre una più semplice gestione del sistema in esercizio; infatti laddove si debba intervenire per rilasciare una patch di tipo correttivo basterà sostituire soltanto la componente che ha evidenziato il problema senza richiedere modifiche di altri elementi dell'architettura applicativa. Inoltre la stratificazione delle componenti garantisce la possibilità di modificarne la strategia di distribuzione sui nodi elaborativi in qualunque momento se ne presenti la necessità per vari motivi. Tutti gli strati applicativi sono strutturati in modo da scambiare messaggi con i livelli adiacenti per garantire la massima indipendenza.

Una cura particolare è stata posta nella progettazione della interfaccia utente; infatti tutti i servizi applicativi sono stati realizzati perseguendo i criteri di web usability, definiti ed accettati dalla comunità internazionale. Inoltre è stata posta particolare attenzione alla realizzazione di interfacce utente accessibili, conformemente alle raccomandazioni del progetto Web Accessibility Initiative del W3C e alle disposizioni della legge n. 4 del 9 gennaio 2004 sull’accessibilità. A conclusione dell’attività di progettazione della interfaccia sono state sempre condotte procedure di verifica dell’usabilità e dell’accessibilità, in alcuni casi con il diretto coinvolgimento degli utenti. Da un punto di vista architetturale tutti i servizi che prevedono l’interazione con l’utente sono stati progettati adottando il pattern Model View Controller (MVC), garantendo così un naturale disaccoppiamento tra logica di presentation e logica di business e/o di accesso ai dati

L’architettura dei servizi applicativi di rete è stata concepita in conformità alle indicazioni del CNIPA in materia di cooperazione applicativa ed offre servizi di base per realizzare modelli di cooperazione per invocazione di servizi (Service Oriented Ardchitecture). Le Aziende Sanitarie esponendo questi servizi potranno partecipare ad uno o più Domini di Cooperazione, fornendo ai soggetti cooperanti e alla collettività punti di scambio delle informazioni predefiniti e con interfacce ben note (web services), che operano secondo regole condivise. A loro volta potranno beneficiare dei servizi che altre Aziende Sanitarie cooperanti vorranno esporre sulle loro porte di dominio. Le regole di interazione, gli standard di formato ed i protocolli adottati sono quelli definiti dal CNIPA e dalla Presidenza del Consiglio dei Ministri nelle specifiche tecniche della Busta di e-Government: XML, SOAP; stessa cosa vale per l’accesso ai cataloghi comuni e per l’autenticazione: LDAP e UDDI.

Metodologia object oriented per lo sviluppo

Per le attività del processo di sviluppo si è fatto riferimento ai workflow, ai workflow detail e alle activity della metodologia Rational Unified Process.

La metodologia RUP (Rational Unified Process) è un processo di software engineering che definisce un approccio formalizzato e standardizzato per l'assegnazione di compiti e responsabilità all'interno di un'organizzazione che progetti e sviluppi sistemi software. Essa si basa sul Processo Unificato (Unified Process, UP) standardizzato da OMG (Object Management Group) nel maggio del 2002 e alla cui elaborazione hanno contribuito importanti aziende operanti nell'Information Technology quali IBM, Microsoft, Unisys e Toshiba.

Le attività di RUP creano e mantengono modelli in accordo con quanto indicato dal Processo Unificato, che preferisce tale forma di rappresentazione delle informazioni - semanticamente più ricca e facilmente leggibile - alla produzione di documenti cartacei di considerevoli dimensioni. RUP si propone quindi come una guida per l'utilizzo dello Unified Modeling Language (UML), linguaggio standard utilizzato per la rappresentazione di requisiti e architetture, anch'esso ideato da Rational Software e successivamente adottato dall'OMG.

RUP è una delle metodologie utilizzate nell’ambito dei processi di sviluppo di Svimservice, conformemente al Sistema Qualità certificato secondo la norma UNI EN ISO 9001:2000.

La metodologia RUP presenta due dimensioni, la dimensione orizzontale che rappresenta il tempo e quindi gli aspetti dinamici del processo al momento della sua attivazione, espressi in termini di fasi, iterazioni e milestones; la dimensione verticale rappresenta invece i workflow principali del ciclo di vita che raggruppano logicamente le attività per natura delle stesse. Questa dimensione rappresenta quindi gli aspetti statici del processo unificato: processi componenti, attività, workflow, artefatti e ruoli coinvolti.

Le fasi di RUP sono le seguenti:

• Inception, vengono individuati gli obiettivi del progetto, i casi d’uso principali ed una prima ipotesi di architettura del progetto; vengono stimati tempi e costi di progetto, individuati i rischi e preparato l’ambiente di progettazione
• Elaboration, si stabilizzano architettura e requisiti e si attuano tutte le azioni necessarie a controllare i rischi di progetto, viene predisposto l’ambiente per lo sviluppo
• Construction, si procede con le attività di sviluppo in maniera iterativo-incrementale, ottimizzando l’utilizzo delle risorse, riutilizzando tutte le componenti architetturali sviluppate ed ottimizzando il livello di qualità dei prodotti, riducendone le non conformità
• Transition, svolgimento di tutte le attività per l’avvio in produzione del sistema: test di accettazione, produzione della documentazione utente, predisposizione della base dati, eventuale avvio parallelo del sistema con altri sistemi legacy

I workflow specificano nel dettaglio le attività dei singoli componenti del team. I principali workflow della metodologia sono:

• Business Modeling
• Requirements
• Analysis & Design
• Implementation
• Test
• Configuration & Change Management
• Project Management
• Environment

L’obiettivo del workflow Business Modeling è quello di effettuare un assessment dell’organizzazione in analisi al fine di verificarne lo stato, definire gli stakeholder, individuare i miglioramenti che è possibile apportare e i goal da raggiungere, comprendere i processi di business e la struttura organizzativa dell’organizzazione; rappresentare sotto forma di business actor e business use case rispettivamente coloro che interagiscono con l’organizzazione ed i processi attivati dall’organizzazione in conseguenza delle suddette interazioni, individuare i processi di business che possono essere automatizzati per aumentare la loro efficienza.

Esso può trovare efficace applicazione nei casi in cui si voglia esaminare un’organizzazione che commissioni un sistema informatizzato per migliorare o reingegnerizzare i propri processi di business, nel caso in cui si abbiano scarse conoscenze sulla business area da analizzare, o ancora qualora si voglia effettuare un’analisi di alto livello ancor prima che sia emanato un capitolato d’oneri al fine di accumulare un vantaggio competitivo.

Nel workflow di Requirements vengono individuati e documentati i requisiti funzionali e non funzionali del sistema/servizio applicativo e gli attori che li utilizzeranno, modellandoli mediante il diagramma dei casi d’uso; i requisiti individuati vengono caratterizzati e viene loro assegnata una priorità per la loro implementazione. Vengono individuate le prime versioni delle classi di interfaccia, definendo una prima ipotesi di interazione fra attori e boundary object. Per i casi d’uso principali e ritenuti a priorità più alta viene predisposto una prima ipotesi di prototipo dell’interfaccia utente.

Nel workflow di Analysis & Design viene effettuata la progettazione del sistema. Durante lo svolgimento di questo workflow vengono definiti gli use case realization (mediante i sequence diagram) ed individuate le classi; in maniera iterativa vengono perfezionati gli use case realization dei casi d’uso e le specifiche delle classi in termini di attributi e metodi. Rientra tra gli obiettivi di questo workfow la definizione dell’architettura del sistema, delle strategie di riuso, dei mechanism comuni all’intero sistema e delle classi che contribuiscono alla loro realization. Viene inoltre definito il deplyment model del sistema.

Con il workflow di Implementation vengono realizzate e testate tutte le componenti e le diverse tipologie di classi che sono state individuate nei workflow precedenti nonché le componenti di integrazione con altri sottosistemi. Viene definito ed implementato lo schema del database, vengono realizzate le componenti di accesso ai dati e la logica di business e di comunicazione. Parallelamente vengono realizzate tutte le componenti che realizzano la logica di presentation (servlet, jsp, fogli di stile) e le componenti che definiscono i servizi pubblicati. Il test viene effettuato utilizzando le procedure di test aziendali a cui si aggiungono test di usabilità e di accessibilità.

Per quanto riguarda le attività di gestione della configurazione e della gestione di progetto, invece di applicare i workflow di Configuration & Change Management e Project Management previsti da RUP, si è preferito applicare le attività previste dalle relative procedure di gestione progetto e di gestione della configurazione previste dal Sistema Qualità Svimservice.