tesi - integrazione di un’applicazione di bpm - visualizzare lo stato di un processo

UNIVERSITA’ DEGLI STUDI DI PADOVA

FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea Triennale in Informatica

Integrazione di un’applicazione di BPM: visualizzare lo stato di un processo

Tesi di Laurea Triennale in Informatica

Relatore: Prof. Livio Colussi

Laureando: Andrea Alberti

Anno Accademico 2009/10

Pagina 2 di 56

Pagina 3 di 56

Indice 1 Introduzione .................................................................................. 1

1.1 Azienda..................................................................................... 2

1.2 Il progetto di stage .................................................................. 4

1.3 Inserimento in azienda e fattori di rischio ............................ 5

2 Pianificazione delle attività........................................................... 7

3 Analisi dei requisiti ...................................................................... 11

3.1 Tecnologie............................................................................... 11

3.1.1 JBoss...................................................................................................... 11

3.1.2 JBPM...................................................................................................... 14

3.1.3 Servlet................................................................................................... 17

3.2 Ambiente di progetto: Finanza 3000.................................... 18

3.3 Use case e descrizioni ........................................................... 24

3.3.1 Utente avanzato.................................................................................. 25

3.3.1 Utente finale ........................................................................................ 26

3.4 Requisiti ................................................................................. 27

3.3.1 Requisiti funzionali ............................................................................. 27

3.3.2 Requisiti di qualità .............................................................................. 28

3.3.3 Requisiti di interfacciamento e di ambiente.................................. 29

4 Realizzazione del prodotto......................................................... 31

4.1 Strumenti per la realizzazione............................................. 31

4.1.1 Netbeans e relativi plug-ins .............................................................. 31

Pagina 4 di 56

4.1.2 Maven plug-in ...................................................................................... 32

4.1.3 Mercurial .............................................................................................. 33

4.2 Installazione e configurazione dell’ambiente ..................... 34

4.3 La JBPM console e la servlet base........................................ 35

4.4 Visualizzazione dell’immagine del grafico dei processi ...... 37

4.5 Visualizzazione dello stato di un’istanza di processo ......... 38

4.5.1 Due soluzioni a confronto................................................................ 38

4.5.2 Visualizzazione mediante codice CSS ............................................. 39

4.6 Analisi statica e dinamica ..................................................... 46

5 Consuntivo e conclusioni ............................................................ 47

5.1 Confronto fra il preventivo ed il consuntivo ....................... 47

5.2 Diagramma di Gantt............................................................. 48

5.3 Analisi critica dello stage ...................................................... 50

Capitolo 1 – Introduzione

1

Capitolo 1

Introduzione

Il corso di laurea in Informatica prevede lo svolgimento di uno stage

presso un’azienda, all’interno della quale si ha l’opportunità di apprendere

le dinamiche di progettazione e sviluppo di un prodotto informatico. La

presente relazione si pone l'obiettivo di illustrare l'attività di stage svolta

presso l'azienda Visionest S.r.l.. Il contatto con l’azienda è stato reperito

grazie all'iniziativa Stage-It promossa dall'Università degli Studi di Padova

per l'anno 2009. Il progetto svolto all’interno della suddetta azienda

consiste nell’integrazione di un’applicazione di business process

management attraverso la visualizzazione grafica dello stato del processo

corrente. Lo scopo dell’attività svolta, che in seguito verrà approfondito, è

stato, in particolare, quello di chiarificare la procedura e snellire

l’acquisizione delle informazioni ad essa relative.


2

1.1 Azienda

Visionest è un’azienda di Padova che opera nel settore della consulenza in

ambito ICT (Information e Communication Technology). La missione

aziendale è di introdurre l’innovazione all’interno delle aziende clienti,

promuovendo il collegamento fra le variabili organizzativa e tecnologica.

Visionest è consapevole che “Organizzazione” e “ICT” sono competenze

che necessitano di essere sviluppate congiuntamente per assicurare il

successo dei progetti di ammodernamento riguardanti le forme

organizzative e gli apparati tecnologici delle imprese, per questo, cerca di

supportare il management sia nella definizione degli obbiettivi strategici,

che nella predisposizione degli strumenti utili alla loro attuazione. Le

organizzazioni che si rivolgono a Visionest manifestano l’esigenza di

rafforzare le proprie abilità nel campo delle tecnologie dell’informazione e

della comunicazione e dell’integrazione dei sistemi informativi e ricercano

perciò un servizio di consulenza completo e approfondito. Visionest mette

a disposizione la propria esperienza dimostrandosi capace di ricoprire un

ruolo non solo di mero fornitore bensì di vero e proprio partner

strategico, su orizzonti di medio-lungo termine. L’azienda opera attraverso

le fasi che partono dallo studio dei requisiti (problem setting) fino a

giungere alla scelta delle soluzioni (problem solving). Laddove, inoltre, le

attività di consulenza investano aree caratterizzate da un alto fattore di

specializzazione, Visionest si mostra in grado di individuare e supportare il

fornitore verticale maggiormente adeguato per la fase di attuazione. In

seno all’impresa opera un gruppo di dieci consulenti che vantano ampie

esperienze di organizzazione e sistemi informativi. La struttura di Visionest

si dirama in quattro macroaree di attività:


3

� Ingegneria ed informatizzazione dei processi (process &

information engineering): verte nella ricerca e realizzazione di

nuovi modelli organizzativi che si realizzano lungo la catena del

valore, includendo l'integrazione con attori a monte o a valle

dell'organizzazione aziendale. Le attività di business process

reengineering (BPR) permetteranno, quindi, di individuare le

soluzioni più appropriate per supportare i processi

dell'organizzazione attraverso il sistema informativo aziendale.

� Gestione strategica della conoscenza (strategic

knowledge): l’organizzazione che intraprende progetti di

knowledge management svolgerà, in modo cosciente e

continuativo, attività di raccolta, organizzazione, condivisione e

analisi della conoscenza presente al suo interno in termini di

risorse, documenti e competenze, attraverso strumenti per il

supporto alle decisioni strategiche e operative.

� Sicurezza e conformità (business & information

protection): Il tema della sicurezza ha come obbiettivo fornire

al management delle organizzazioni gli strumenti per individuare

e monitorare il livello di rischio a cui sono sottoposte le

informazioni gestite dall’azienda. Vengono, inoltre, trattate le

tematiche di conformità a particolari aspetti normativi e

regolamentari (es. privacy – d.lgs. 196/03; Responsabilità persone

giuridiche – d.lgs. 231/01).

� Consulenza IT (IT advisory): Visionest rappresenta per il

cliente, laddove non siano presenti, o vi siano solo parzialmente,

le competenze in materia di information technology , a partire

dalle infrastrutture di comunicazione per arrivare alla gestione

del servizio informatico aziendale.


4

1.2 Il progetto di stage

Visionest cercava uno stagista con le competenze necessarie a portare a

termine un progetto inerente la piattaforma Finanza 3000. Finanza 3000 è

la piattaforma gestionale recentemente adottata, in sostituzione alla

precedente “Finanza 2004”, che oramai mal rispondeva alle esigenze dei

clienti e ai cambiamenti nel contesto normativo. In particolare era

fortemente sentito all’interno di Visionest il bisogno di introdurre un

sistema che permettesse al cliente di implementare e governare i processi

software senza richiedere l’assistenza di sviluppatori e/o tecnici

specializzati. Finanza 3000 è stata sviluppata da Visionest attraverso

l’utilizzo del framework proprietario “aplus BPM” e sfruttando alcune

applicazioni open source, tra le quali JBPM, Drools, ed altre. Il sistema

poggia su un’architettura 3-tiers che distribuisce su tre livelli,

rispettivamente, le componenti che si occupano di memorizzazione e

allocazione dei dati, di esecuzione di operazioni su di essi e di interfaccia

per l’end user. Nell’ambito del sistema gestionale così costituito la parte

sviluppata sull’applicazione di gestione dei processi JBPM necessitava di

alcune rivisitazioni che permettessero di rendere maggiormente agevole

l’utilizzo dello strumento dal punto di vista dell’interfaccia grafica e delle

visualizzazioni. In particolare JBPM presentava delle lacune per quanto

atteneva alla visualizzazione della struttura e dello stato di avanzamento

dei processi. Il progetto di stage attivato presso la Visionest ha, perciò,

avuto come obbiettivo quello di integrare la visualizzazione grafica dello

schema processuale. Nello specifico si è proceduto all’introduzione di

un’immagine che indicasse in maniera chiara lo stato attuale del processo

in ogni fase di avanzamento e la possibilità di interrogare il sistema per


5

ottenere ulteriori informazioni quali altri metadati e variabili coinvolti nello

svolgimento delle attività. La pianificazione delle attività e l’attuazione dei

compiti affidati allo stagista saranno esaminati nel dettaglio nel corso della

trattazione.

1.3 Inserimento in azienda e fattori di rischio

Lo stagista si è inserito nell’ambiente aziendale grazie all’affiancamento del

tutor, Michele Mauro, programmatore all’interno di Visionest. Il dott. Mauro

ha curato le comunicazioni con lo stagista e si è occupato di svolgere una

funzione di intermediazione per il suo inserimento all’interno delle attività

dell’impresa. Per ciò che riguarda in maniera particolare i rischi collegati

allo svolgimento del lavoro di stage, se ne possono individuare due

categorie: i fattori di rischio meramente tecnici e quelli invece legati

all’ambito strategico. Tra i rischi di natura tecnica si ritrovano in

particolare:

� la scarsa familiarità con l’ambiente e il linguaggio di sviluppo;

� le difficoltà legate a problemi di comprensione riguardanti i

requisiti del programma e i bisogni dell’azienda ;

� la variazione della tecnologia in uso.

Come fattori di rischio di tipo strategico si individuano, invece:

� impossibilità per lo stagista di recarsi sul posto di lavoro (causata

da malattia, sciopero dei mezzi di trasporto, ecc);


6

� rispetto delle tempistiche durante il periodo di svolgimento delle

attività;

� scarsa adattabilità a nuovi metodi di impostazione del lavoro.

Capitolo 2 – Pianificazione delle attività

7

Capitolo 2

Pianificazione delle attività

Lo stage avrà una durata complessiva di 300 ore. Ogni settimana è

composta da 5 giorni lavorativi di 8 ore ciascuno per un totale stimato di 7

settimane e mezza. Il dettaglio delle modalità operative è stato concordato

assieme al tutor Michele Mauro, con scadenza pressoché settimanale.

Piano di contingenza e revisioni: “Qualora dovessero presentarsi delle

anomalie gravi che richiedano immediata attenzione, può essere

concordato un giorno a settimana per affrontare tali problematiche, in

modo da abbassare l’influenza dei fattori di rischio con l’assistenza del

tutor presente all’interno dell’azienda.”. Per correggere eventuali errori,

sono previste una serie di revisioni formali, da svolgersi con il tutor

aziendale per tutta la durata dello stage. Suddette revisioni avranno luogo

al compimento di ogni fase definita del progetto e si focalizzeranno su

eventuali anomalie riscontrate durante tale arco di tempo. La seguente

tabella riporta il piano preventivato per ogni settimana di lavoro a partire

dal 28/09/2009 con indicazione delle principali attività e del carico di


8

lavoro stimato.

SETTIMANA ORE ATTIVITA’

1 40 - comprensione dell’ambiente di utilizzo del

sistema e degli strumenti di sviluppo

- setup e preparazione dell’ambiente di

lavoro

- pianificazione del progetto e relativa

documentazione

2 40 - analisi del framework Spring

- studio di JBPM

3 40 - analisi e rilevazione del modo in cui la

feature è realizzata nella console standard

- analisi della struttura dei metadati

4 40 - studio dell’applicazione esistente sulla base

delle informazioni reperite in precedenza

- produzione della documentazione di

analisi

5 40 - progettazione che dovrà risolvere

principalmente due problemi: come

recuperare i dati e visualizzarli per l’utente,

come caricare le immagini

6 40 - stesura dei documenti di progettazione

- codifica della parte logica


9

7 40 - codifica della parte grafica

- integrazione e standardizzazione con il

sistema

- verifica e validazione tramite test

8 20 - correzione degli errori

- stesura della documentazione finale

Come si nota chiaramente dalla tabella, durante le prime fasi del progetto

un consistente numero di ore è stato dedicato alla comprensione

dell’ambiente di sviluppo e allo studio delle soluzioni già presenti

nell’ambiente aziendale. In particolare risulta evidente come più del 45%

delle ore lavorative siano state impiegate per un’accurata preparazione

della piattaforma di lavoro, per lo studio dei sistemi implementati e per la

produzione dei documenti relativi all’analisi. Solo nella successiva fase

attuativa si avrà l’occasione di apprezzare quanto un’attenta e scrupolosa

analisi sia fondamentale per snellire e facilitare lo svolgimento delle attività

operative.

La seconda parte del progetto è stata dedicata allo svolgimento di attività

di progettazione legate alla ricerca di soluzioni idonee per problemi quali:

� recupero e visualizzazione dati;

� caricamento immagini;

ed in massima parte alla stesura del codice sia per quanto attiene alla parte

logica, sia per quanto attiene alla parte grafica. Il progetto ha trovato la sua

naturale conclusione nello svolgimento di attività di test e verifica mirate a

collaudare il funzionamento integrato delle applicazioni e nella stesura della

documentazione finale.


10

Le fasi nodali, sulle quali era focalizzato il preventivo originario, erano le

seguenti:

� Inserimento nel contesto aziendale e acquisizione di skills relative

alle prassi operative adottate all’interno del contesto lavorativo;

� Comprensione della situazione che si presentava e analisi delle

logiche di intervento;

� Studio di una soluzione efficiente rispetto agli obiettivi;

� Realizzazione delle parti software e verifica della rispondenza alle

funzionalità richieste;

� Verifica dell’integrazione e della standardizzazione con il sistema;

� Verifica del funzionamento e correzione di eventuali errori.

Al di là delle naturali complessità relative alle fasi di codifica, dovute al tipo

di attività che richiede specifiche e mirate competenze in materia, una delle

difficoltà maggiori è stata riscontrata nella necessità di integrare

l’applicazione all’interno di un sistema già presente, quindi di individuare

una serie di caratteristiche che permettessero al software di funzionare

sinergicamente col sistema nel suo complesso.

Capitolo 3 – Analisi dei requisiti

11

Capitolo 3

Analisi dei requisiti

3.1 Tecnologie

Le tecnologie utilizzate nel progetto fanno parte della piattaforma JEE, che

è costituita da un insieme di specifiche che definiscono le caratteristiche e

le interfacce di un insieme di tecnologie pensate per la realizzazione di

applicazioni di tipo Enterprise. Queste componenti estendono le

funzionalità di base della piattaforma Java e la rendono quindi facile la

realizzazione di un’implementazione di tali specifiche per produrre

application server compatibili.

3.1.1 JBoss

JBoss è un application server open source che implementa l’intera suite di


12

servizi legati allo standard J2EE. Il programma è interamente compilato in

linguaggio Java, ed è, perciò, utilizzabile da qualsiasi sistema operativo che

supporti Java. Un application server è un’applicazione che fornisce

l’infrastruttura, le funzionalità esecutive e di supporto necessarie per

l’implementazione di componenti server in un contesto distribuito. In

particolare, gli application server sono utilizzati per la realizzazione di

applicativi complessi, solitamente multilivello ed Enterprise, orientate per

gli sviluppi sul web. Un application server è generalmente costituito da

moduli generati seguendo schemi strutturali standard, generalmente

approvati dalla comunità dei programmatori (ad esempio il protocollo

HTTP). All’interno di un application server è inoltre possibile fare operare

una servlet che sarà appunto l’obiettivo del progetto di stage.

I moduli che solitamente si ritrovano in un application server sono i

seguenti:

� contenitore di componenti server-side;

� gestore degli accessi degli utenti e della sicurezza;

� gestore accessi a database o, in generale, a sorgenti dati esterne;

� gestore delle transazioni;

� interfaccia per accesso a sistemi lagacy;

� altri componenti utili per la massimizzazione delle prestazioni.

Lo sfruttamento di programmi di tipo application server presenta

numerosi benefici legati allo sviluppo, all’esecuzione e alla gestione

integrata dei sistemi, quali:

� Semplificazione delle attività di sviluppo, ottenuta grazie alla

possibilità di usare gli strumenti a maggiore diffusione sul mercato,

che permettono di produrre e distribuire in modo rapido ed efficace


13

applicazioni transazionali altamente scalabili;

� Riduzione dei tempi di realizzazione e messa in esercizio dei

programmi negli ambienti distribuiti;

� Supporto di vari linguaggi;

� Riusabilità del codice grazie all’uso delle tecniche di

programmazione ad oggetti e dell’approccio a componenti, la logica

applicativa può essere condivisa e riutilizzata;

� Gestione delle transazioni e garanzia dell’integrità transazionale e

dell’affidabilità dei back-end multipli per le risorse e i dati;

� Scalabilità: sono supportati il partizionamento delle applicazioni e la

distribuzione in rete delle componenti;

� Alte Prestazioni: gli application server sono configurati con

determinate caratteristiche architetturali che permettono di erogare

alte prestazioni: multithreating, load balancing, caching e pooling degli

oggetti e delle connessioni di database;

� Estendibilità: l’architettura modulare e il supporto per moduli e

server permettono di caricare dinamicamente gli elementi;

� Robustezza: i componenti del server e la logica applicativa possono

essere riconfigurati, aggiunti o rimossi senza interrompere

l’erogazione del servizio, ciò rende i sistemi altamente disponibili e

permette di non interferire con lo svolgimento di core activities

aziendali;

� Sicurezza: gli application server implementano funzioni spoecifiche di

sicurezza end-to-end, necessarie per la messa a punto di operazioni

aziendali che richiedano alti livelli di controllo e sicurezza sui dati. Le

comunicazioni fra client e server sono preservate attraverso l’uso di


14

algoritmi standard ampiamente testati e collaudati sul web ( ad

esempio quelli offerti dal protocollo SSL), e sono forniti servizi di

protezione relativi agli accessi non autorizzati.

JBoss, in particolare, sfrutta la tecnologia Java, per la cui produzione

l’azienda Sun si avvale del lavoro sinergico svolto da sviluppatori di tutto il

mondo. E’ per questo motivo che, grazie anche al supporto della comunità

open source l’applicazione JBoss mostra qualità notevoli in termini di

affidabilità, robustezza e flessibilità e occupa una posizione di leadership nel

mercato degli application server open source.

3.1.2 JBPM

JBPM è una libreria open source. Fornisce una piattaforma per i linguaggi di

processo che vanno dal business process management (BPM) sui workflow

alla service orchestration. Supporta 3 diversi tipi di linguaggi di processo,

ognuno dei quali è mirato verso una specifica funzione e ambiente: jPDL,

BPEL, Pageflow. Tutti e tre sono sviluppati nativamente in seno ad una

singola tecnologia: la Process Virtual Machine (PVM) che è una semplice

libreria Java per lo sviluppo e l’esecuzione di grafici di processi.

FIGURA 3.1


15

Le funzionalità della piattaforma utilizzate riguardo al progetto di stage

saranno quelle relative al BPM ed il linguaggio jPDL.

BPM

Il Business Process Management è l’insieme di attività necessarie a creare,

organizzare, gestire e migliorare i processi di business. La caratteristica

peculiare del BPM consiste nell’avvalersi della tecnologia dell’informazione

e della comunicazione (ICT) per amministrare i processi operativi delle

imprese e incrementarne l’efficienza e l’efficacia. L’elemento innovativo è,

perciò, costituito dalla possibilità, offerta dal BPM, di integrare le variabili

tecnologica e organizzativa per migliorare sensibilmente la gestione dei

processi d’impresa. L’utilizzo di logiche di BPM permette di risparmiare

tempo durante lo svolgimento dei processi e, quindi, di guadagnare risorse

utili che possono venir utilizzate nelle core activities dell’impresa. Le

applicazioni di BPM permettono di elaborare un gran numero di variabili

quantitative in real time, e, così, di scambiare informazioni utili relative allo

stato di avanzamento dei processi e alle attività che li compongono, in

modo da mettere in grado gli operatori di svolgere le proprie mansioni in

modo più efficiente e produttivo. Le piattaforme che utilizzano software

modellati sulle logiche di BPM permettono di rendere più chiare le

procedure dell’azienda, sia per ciò che attiene alla successione delle attività,

sia per quanto riguarda la visualizzazione grafica del complesso delle

operazioni in corso di esecuzione. I programmi che riguardano il business

process management possono basarsi su più applicativi differenti e integrati

solo successivamente, oppure su software nativamente integrati. Una delle

possibilità più interessanti che si aprono attraverso l’utilizzo di questo tipo

di applicazioni si riferisce alle caratteristiche sempre più avanzate dei

programmi che si inquadrano nelle logiche di BPM. I più moderni standard


16

nell’ambito dell’ICT permettono, infatti, di inserire in queste piattaforme

alcuni software in grado di analizzare grandi quantità di dati e di fornire

così report dettagliati che agevolano l’analisi dei processi, consentendo al

management di improntare nuove e più efficaci strategie operative laddove

riscontrassero lacune e malfunzionamenti nell’avanzamento delle attività.

Le applicazioni software create secondo questa logica risultano, perciò,

modellate secondo la struttura dei processi lavorativi aziendali, dei quali

ricalcano l’intelaiatura sia per ciò che riguarda l’ambito applicativo, sia per

quanto attiene al contesto dell’interfaccia utente (Figura 3.2)

FIGURA 3.2

Il BPM trascina con sé due importanti vantaggi. Innanzi tutto, costringe alla

costruzione di un dialogo tra chi svolge un ruolo all’interno degli apparati

organizzativi e chi si occupa della questione tecnologica, in modo da

integrare organizzazione e tecnologia per raggiungere eccellenti risultati in

termini di sfruttamento delle potenzialità dei moderni software gestionali.

In secondo luogo, consente di monitorare i miglioramenti di performance

dovuti all’implementazione del software e, quindi, permette di estrapolare

dati utili per creare strategie volte ad un ancora maggiore miglioramento


17

dell’efficienza.

JPDL

JPDL è un linguaggio di processo caratterizzato da una spiccata versatilità,

offre diverse possibilità di integrazione con Java e si mostra maneggevole

nell’ambito dell’ organizzazione dei task. La base del linguaggio è costituita

dalla grafica e ciò determina un notevole incremento della semplicità d‘uso

di JPDL, in questo modo la transizione fra il modello di analisi e il modello

di esecuzione diviene estremamente facile e comprensibile. Può essere

utilizzato in due modalità: attraverso un designer, oppure tramite una

basilare sintassi XML. Viene fornito in una suite corredata da tutti gli

elementi: il designer, la documentazione, gli esempi, le librerie.

3.1.3 Servlet

Una servlet è un programma eseguibile in un application server (nel nostro

caso JBoss) ed ha molteplici funzionalità. Nella maggior parte dei casi,

tuttavia, viene sfruttato per la generazione di pagine web in forma dinamica,

a seconda dei parametri della richiesta che sono spediti dal browser. La

servlet è, quindi, un programma che deve rispettare determinate regole e

che processa una richiesta HTTP in una maniera specifica. All’interno dello

stesso application server possono, naturalmente, girare più servlets,

associate a indirizzi diversi e, dunque, con compiti diversi; sarà, così,

ampliata l’estensione delle funzionalità del web server. La realizzazione di

una servlet che estenda le funzionalità di una applicazione web di Visionest

è proprio l‘obbiettivo primario del progetto qui descritto.


18

3.2 Ambiente di progetto: Finanza 3000

Finanza 3000 è un sistema informativo gestionale progettato e realizzato

ad hoc per l’amministrazione dei servizi di erogazione di prodotti di

Finanza Agevolata. Il prodotto è destinato ad operatori finanziari, pubblici e

privati, e permette di gestire agevolmente ed in maniera completa i fondi di

terzi (fondi pubblici, statali, regionali, UE) e il rilascio di garanzie (Confidi). Il

gestionale mira, nello specifico, a risolvere i problemi di back office

(gestione operativa), controllo e reporting di processi istruttori,

rendicontazione ed erogazione di fondi. La peculiarità di Finanza 3000 è il

riferimento a due concetti innovativi, che abbandonano la strada delle

architetture gestionali di transizione, per concentrarsi su due punti

fondamentali:

� La gestione per processo - definisce e controlla un processo end -

to - end dall’inizio alla fine;

� La gestione dei contenuti - organizza i documenti e le informazioni

afferenti i processi operativi in ambiente internet e intranet.

In particolare, il processo di istruttoria viene gestito dalla fase di start alla

fase di end, seguendo le linee organizzative del back e front office e

integrando le componenti di calcolo finanziario e le regole di compliance.

Finanza 3000 è organizzato in moduli nativamente integrati che si snodano

attraverso tre macrosezioni gestionali:

1. GESTIONALE che comprende i moduli:

� Anagrafica (il programma si integra con l‘anagrafica aziendale per


19

gestire in modo centralizzato e sicuro i soggetti coinvolti a vario

titolo nello svolgimento dei processi. Permette di censire gli attori

delle attività finanziarie e di certificare le informazioni acquisite

attraverso l‘integrazione con i servizi infocamere.);

� Gestione del sistema (organizza i parametri di configurazione dei

processi, delle regole e dei vocaboli di business,dei dizionari dati, dei

ruoli utente e dei report.)

� Tassi e cambi (consente di gestire i valori di tassi e cambi anche

attraverso la storicizzazione).

2. PROCESSI che è costituita dai moduli:

� Finanziamenti (governa tutte le fasi di erogazione del finanziamento,

dall‘istruttoria all‘estinzione, passando per la rendicontazione e la

gestione post vendita);

� Contributi (si occupa della gestione dei contributi, amministrando il

processo in tutte le sue fasi);

� Prodotto complesso (consente la gestione di tutti gli strumenti

finanziari complessi: combinazioni di leasing-finanziamenti contributi

e garanzie).

3. DIREZIONALE, composta dai moduli:

� Report operativo (genera un set completo di report per supportare

le funzioni di back e front office, producendo documenti utili agli

attori interni - CDA, direzione finanza, direzione generale, ecc. - ed


20

esterni - beneficiari, intermediari finanziari, banche, ecc. - );

� Report direzionale (permette l‘estrapolazione dei report necessari a

coadiuvare le funzioni direzionali e di controllo);

� Report engine (consente di generare qualsiasi genere di reportistica

specifica);

� BAM - business activity monitoring (calcola gli indicatori di

performance relativi ai processi gestiti con Finanza 3000 e agevola le

stime dei miglioramenti che si riscontrano con l‘uso del gestionale).

Per lo sviluppo di Finanza 3000 Visionest ha utilizzato il framework

proprietario “aplus“. Nell’ambito di questo framework viene collocato il

progetto per lo stagista. Aplus è una potente piattaforma di BPM

attraverso la quale si rende possibile l’implementazione di applicazioni che

hanno come scopo la gestione dei processi organizzativi, l’evoluzione degli

stessi con un sostanziale contenimento dei costi e lo sviluppo di complesse

applicazioni che si prestino ad essere utilizzate dagli utenti di front e back

office. Visionest per rendere più efficienti le attività di progettazione del

software Finanza 3000 ha adottato un “principio progettuale”. Questo

“principio” è servito ad assegnare in maniera precisa i ruoli specifici ad

ognuna delle componenti architetturali, consentendo di focalizzare i

compiti che la piattaforma aplus avrebbe dovuto assolvere nell’ambito di

ciascuna componente. In particolare, sono state evidenziate le

“responsabilità” che ha lo strumento aplus nei confronti dei compiti da

svolgere:

� Definire i processi di business;

� Definire le condizioni che devono essere soddisfatte affinchè un

processo possa passare da uno stato al successivo;


21

� Fornire strumenti per verificare il comportamento del processo e le

sue correlazioni con altri processi sistema prima della messa in

opera;

� Decidere quali utenti hanno accesso all’applicazione e con che

privilegi;

� Produrre rapporti a partire dalla struttura del processo e dal suo

stato;

� Operare in tempo reale sui processi;

� Permettere l’apporto di nuove informazioni da parte di utenti

esterni;

� Fornire a potenziali beneficiari informazioni riguardo i processi

disponibili.

La piattaforma aplus è stata creata sulla base di un framework strutturato

su tre componenti essenziali (Fig. 3.3: componenti del framework di aplus,

fonte “aaaPLUS”,Visionest srl).:

1. BPMS - business process management system - motore di elaborazione

dei processi, è il nucleo del sistema. I processi memorizzati nel database

vengono eseguiti in tempo reale e i relativi output sono visualizzabili

attraverso l’interfaccia utente, oppure traducibili in diversi tipi di report e

stampabili.

2. CMS - content management system - modulo di gestione dei contenuti,

è un’applicazione affidabile che nasce integrata con i servizi di BPM.

3. PMS - performance management system - modulo estrazione dei

report. E’ un motore di estrazione, elaborazione, aggregazione e

presentazione dei dati analitici che circolano all’interno del sistema: sia per

ciò che riguarda le pratiche finanziarie, sia per quanto attiene all’efficienza


22

con la quale vengono svolti i processi.

FIGURA 3.3

E’, inoltre, presente, un tool grafico (modulo disegno dei processi) che

permette di chiarificare le fasi del processo attraverso la sua

rappresentazione grafica.

Le componenti del framework sono state sviluppate attraverso moduli

dedicati (Fig. 3.4: complesso dei moduli componenti il framework, fonte

“aaaPLUS”, Visionest srl.):

� il motore di BPM;

� il motore di CMS;

� il motore di DWH;

� Il DB;

� il BUS di integrazione;

� il modulo di U.I.;

� il modulo di analisi dei processi.


23

FIGURA 3.4

L’architettura di Finanza 3000 è di tipo service oriented, strutturata in

moduli e componenti collegati fra loro dal framework Spring, leader nel

campo delle moderne applicazioni Java Enterprise. I moduli si basano su

foundation opensource altamente affidabili, quali:

� Il motore di BPM (JBPM, JBoss);

� Il motore di CMS (Alfresco);

� Il motore di DWH (Jasper Reports);

� BUS di integrazione (JBoss ESB);

� Il modulo di U.I. (EXT JS);

� Il modulo di analisi dei processi (JBPM, o altri tool standard quali

BPM - Visual, Paradigm, Oynx).


24

Il database, infine, può essere di qualsiasi tipo, visto l’utilizzo della libreria di

persistenza Hibernate che consente di utilizzare qualsiasi database

relazionale come back-end.

FIGURA 3.5

3.3 Use case e descrizioni

In questa sezione vengono analizzate e descritte le funzioni che il sistema

offre, così come percepite dagli utenti che interagiscono con il sistema

stesso; si rappresentano, inoltre, i requisiti funzionali del prodotto. Essi


25

saranno essenzialmente due: l’utente avanzato (business user) e l’utente

finale.

I diagrammi sono accompagnati dalle loro descrizioni, per consentire una

migliore comprensione.

3.3.1 Utente avanzato

L’utente avanzato, detto anche business user, vuole controllare il grafico di

una definizione di processo caricato a sistema, quindi richiede al sistema

l’intera immagine.

FIGURA 3.6

ATTORI COINVOILTI: solamente l’utente finale

PRECONDIZIONE: l’utente ha effettuato il login con esito positivo e si

trova quindi nella condizione di poter consultare il grafico.

AZIONE: l’utente può consultare il grafico generale tramite richiesta

HTTP alla servlet.


26

3.3.1 Utente finale

L’utente finale ha bisogno di capire dove un’istanza di processo si trovi

all’interno del grafico, quindi richiede la definizione del processo

dell’istanza in cui sta lavorando, annotata con evidenziato il nodo corrente.

FIGURA 3.7

ATTORI COINVOILTI: solamente l’utente finale

PRECONDIZIONE: l’utente ha effettuato il login con esito positivo e si

trova quindi nella condizione di poter consultare il grafico.

AZIONE: l’utente può consultare il grafico con evidenziato il nodo

corrente tramite richiesta HTTP alla servlet.


27

3.4 Requisiti

In questa sezione saranno elencati i requisiti del prodotto, utilizzando una

opportuna classificazione per aiutarne la lettura.

Per tali requisiti sarà adottata una apposita nomenclatura:

� Una lettera iniziale per tutti “R” ad indicare che si tratta di un

requisito;

� Una lettera identificativa per specificarne la tipologia: “F” funzionale,

“Q” di qualità, “I” di interfacciamento ed ambiente;

� Una lettera per identificarne la priorità: “O” obbligatorio, “D”

desiderabile, “P” opzionale;

� Un numero univoco progressivo per i requisiti della categoria.

3.3.1 Requisiti funzionali

OBBLIGATORI:

� RFO01: deve rendere visualizzabile lo stato del processo corrente

� RFO02: il prodotto deve essere una servlet

� RFO03: il prodotto deve essere una funzione a se stante integrabile

nella applicazione esistente

DESIDERABILI:


28

� RFD04: possibilità di visualizzare lo stato del nodo ossia se in

esecuzione, sospeso o cancellato

OPZIONALI:

� RFP05: possibilità visualizzare il nome del task del nodo corrente

� RFP06: possibilità di visualizzare i metadati coinvolti nel processo

3.3.2 Requisiti di qualità

OBBLIGATORI:

� RQO01: Il prodotto deve garantire un livello accettabile di

affidabilità

� RQO02: il prodotto deve essere facile da modificare e integrare in

vista di future rivisitazioni da parte del team di Visionest

DESIDERABILI:

� RQD03: la visualizzazione dello stato dovrebbe essere comprensibile

all’utente

� RQD04: produzione di una adeguata documentazione

� RQD05: il codice possibilmente ben commentato


29

OPZIONALI:

� RQP06: il prodotto risponde in tempi brevi alla richiesta HTTP

3.3.3 Requisiti di interfacciamento e di ambiente

OBBLIGATORI:

� RIO01: l’applicazione web deve essere compatibile con i browser più

diffusi (Explorer, Firefox, Safari, Chrome, ecc);

DESIDERABILI:

� RID02: la servlet è realizzata partendo da uno scheletro per

l’automazione del progetto maven

OPZIONALI:

� RIP03: la servlet dovrà interfacciarsi durante la messa in produzione

al gestionale Finanza 3000 di Visionest


30

Capitolo 4 – Realizzazione

31

Capitolo 4

Realizzazione del prodotto

In questo capitolo vengono esposte le considerazioni e le descrizioni del

prodotto, motivando le scelte architetturali ed altre decisioni tecniche.

Sono, inoltre, presentati gli strumenti utilizzati per la realizzazione, e le

descrizioni dettagliate delle componenti.

4.1 Strumenti per la realizzazione

4.1.1 Netbeans e relativi plug-ins

L’ambiente di sviluppo (IDE) è stato NetBeans. Questo ambiente è stato


32

sviluppato dalla Sun Microsystem e rilasciato con una particolare licenza

open-source (CDDL che sta per Common Development and Distribution

License).

Esso fornisce una base multi-linguaggio, ma è scritto interamente in Java

mediante l’utilizzo delle librerie grafiche standard (Swing).

Poiché scritto in Java, il suo punto di forza primario è la versatilità, ossia la

disponibilità a lavorare con numerose piattaforme.

Inoltre, grazie alla sua struttura basata sui plug-ins, si offre come ambiente

di sviluppo software per i più svariati linguaggi di programmazione ed

integra molte altre funzioni utilissime allo sviluppatore,quali la

compilazione assistita, il versionamento dei files e le modellazioni UML.

Il motivo per cui NetBeans è stato scelto, in accordo con il tutor aziendale,

è stata essenzialmente la dimestichezza precedentemente acquisita dallo

stagista con tale strumento nell’ambito del progetto di ingegneria del

software.

4.1.2 Maven plug-in

Nel corso della codifica si è sentita la necessità di uno strumento che

rendesse pratica e veloce la stesura delle servlet, quindi, con l’assenso del

tutor aziendale, si è scelto di utilizzare il plug-in standard di Maven per

Netbeans. Maven è uno strumento software per l’organizzazione dei

progetti e la costruzione automatica sviluppato dalla Apache software

foundation e rilasciato con una licenza software free, compatibile con la

GNU GPL. Si tratta di uno strumento autoinstallante, che procede

all’installazione non appena si effettua il download automatico tramite il


33

gestore di plug-ins proprio dell’IDE.

Questo strumento è predisposto per la rete in quanto scarica in maniera

autonoma le librerie Java necessarie e i Maven plug-ins dai vari repository.

Maven ha la caratteristica di possedere un costrutto particolare

conosciuto come Project Object Model (POM) per descrivere il progetto

software, le sue dipendenze da moduli e componenti esterni e l’ordine di

costruzione.

Questo plug-in è stato utile nell’ambito del progetto per la costruzione di

una servlet definita di base, al fine di estendere successivamente le sue

funzionalità con la visualizzazione dell’immagine del grafico di processo

richiesta dall’utente.

4.1.3 Mercurial

Uno strumento già utilizzato presso l’azienda Visionest è Mercurial, un

sistema distribuito di versionamento del codice, open-source e disponibile

per gli ambienti più diffusi. Fin dall’inizio si è avvertita la necessità di tale

strumento, per permettere al tutor aziendale di seguire gli steps realizzati

giornalmente, consigliare e correggere il lavoro dello stagista, disponendo

in tempo reale delle varie versioni prodotte.

Questo tool consente, infatti, di eseguire tutte le operazioni di gestione

delle versioni principali (inserimento, rimozione, modifica e merging)

fornendo, contemporaneamente, supporto alla condivisione dei repository

in modo distribuito.

La sua particolarità sta nel fatto che ogni repository creato con Mercurial

può essere scambiato e aggiornato, attraverso l’utilizzo di bundle


34

(pacchetto contenente tutte le modifiche a partire da una certa revisione),

in maniera tale da consentire al ricevente di applicare semplicemente le

modifiche al proprio repository locale, ottenendo una stessa versione

finale ed una sincronizzazione dei contenuti.

4.2 Installazione e configurazione

dell’ambiente

L’installazione e la configurazione dell’ambiente è avvenuta con l’assistenza

diretta del tutor aziendale, affinché fosse possibile iniziare il lavoro

disponendo dei programmi corretti nella versione idonea. Ovviamente, è

stata prima verificata all’interno del sistema la presenza di Java EE, per poi

procedere all’installazione dei tre strumenti sopra elencati.

E’ stato inoltre aggiunto il bundle di JBPM in versione 3.2.1 contenente

l’application server JBoss, la libreria JBPM, la documentazione e i relativi

plug-ins per gli IDE più comuni (Eclipse, Netbeans, eccetera).

Questo bundle è stato utile soprattutto per l’ampia documentazione

contenuta al suo interno. Questo manuale ha rappresentato infatti una

fonte adeguata per comprendere la struttura dei metadati utilizzati da

JBPM e, inoltre, per capire in che modo la console standard interagisca con

le servlet, inquadrando il tutto nell’ambito delle funzionalità del sistema,

analoghe a quelle del gestionale di Visionest.


35

4.3 La JBPM console e la servlet base

La JBPM console standard è un applicativo di esempio che utilizza le

funzioni della libreria JBPM. Al suo interno possiede delle servlets

predefinite che sono state prese come punto di partenza per la

realizzazione della nuova servlet. E’ stata dunque studiata la

documentazione di questa console per comprendere la struttura dei

metadati, delle funzioni di base e l’interazione con questi ultimi.

La servlet, in seguito all’avvio del web server JBoss, deve rispondere ad una

richiesta HTTP da parte del browser. La richiesta può configurarsi come

segue:

http://localhost:8080/ProcessImage-0.1/processImage?definitionId=2

In questo path è inserita la richiesta ad una data servlet di un certo id di

processo. Essa andrà a reperire l’immagine per visualizzarla all’interno del

browser e renderla disponibile all’utente.

La cosa può essere resa in modo grafico attraverso il seguente diagramma

di sequenza:


36

FIGURA 4.1

Secondo queste specifiche, grazie all’aiuto di Maven, è stato possibile

produrre una servlet base, senza funzionalità integrate, ma che rispondesse

correttamente ad una richiesta HTTP all’interno della JBPM console.

Questo avviene perché è stata costituita una classe derivata da

HttpServlet:

public class processImageServlet extends HttpServlet

Suddetta classe, nel momento evidenziato, non fa altro che visualizzare una

pagina bianca nel browser. A partire da questo primo step si è potuta

avviare la realizzazione del progetto.


37

4.4 Visualizzazione dell’immagine del grafico

dei processi

Tramite la libreria JBPM è possibile estrarre dal database l’immagine

generale del processo, ossia quella che incorpora il workflow completo dei

processi. Questo è il risultato del primo obbiettivo del progetto di stage,

ed è stato possibile raggiungerlo partendo dalla servlet base

precedentemente creata, con l’innesto di funzionalità atte a svolgere il

compito richiesto.

Ciò avviene essenzialmente tramite la classe processImageServlet che

possiede al suo interno la funzione:

protected void doGet(HttpServletRequest request, HttpServletResponse

response)

che acquisisce l’id dell’immagine indicata dall’utente e, in seguito, ricerca

nel database l’immagine richiesta, tramite il comando:

processDefinition.getFileDefinition().getBytes("processimage.jpg")

Questo è possibile in quanto JBPM chiama, di default, tutte le immagini

create con lo stesso nome ed estensione, ossia processimage.jpg.

In questo modo l’immagine viene individuata e mostrata nel browser; è

stato così prodotto il primo output del progetto e relativala funzionalità è


38

stata messa in produzione all’interno del gestionale di Visionest, di cui

possiamo vedere a seguito uno screenshot di effettivo utilizzo.

FIGURA 4.2

4.5 Visualizzazione dello stato di un’istanza di

processo

4.5.1 Due soluzioni a confronto

Per quanto riguarda la realizzazione della funzionalità di visualizzazione

dello stato di un’istanza di processo per l’utente finale, in prima battuta è


39

stata ricercata una soluzione, poi bocciata a favore di un’altra.

Dapprima si era pensato, infatti, di seguire una interpretazione secondo la

quale si lavorava sull’immagine stessa, presa dal database come spiegato in

precedenza. L’immagine sarebbe stata reinterpretata e ad essa si sarebbe

aggiunta una cornice in via grafica. Infine si sarebbe proceduto ad un

secondo salvataggio che visualizzava il processo corrente così incorniciato.

Questa opzione sarebbe stata complessa dal punto di vista realizzativo,

perché richiedeva librerie grafiche per poter reinterpretare l’immagine.

Inoltre la servlet avrebbe necessitato di un tempo eccessivo per

rispondere alla richiesta, quindi è stata solo analizzata e mai sviluppata. Con

l’approvazione del tutor aziendale si è, quindi, pensato di intraprendere

un’altra via.

Attraverso un‘approfondita analisi si è giunti alla conclusione che sarebbe

stato conveniente procedere con la realizzazione di una maschera da

apporre all’immagine tramite codice CSS e HTML per evidenziare lo stato

corrente. In questo modo, non si sarebbe resa necessaria nessuna

manipolazione all‘immagine.

La soluzione è stata inizialmente proposta a livello teorico allo staff di

Visionest, e, solo in seguito all’approvazione è stato possibile avviare il

lavoro. L’iniziativa è risultata valida in quanto sarebbe stato possibile

integrarla agilmente anche all’interno dell’ambiente gestionale Finanza

3000.

4.5.2 Visualizzazione mediante codice CSS

La visualizzazione dello stato di processo corrente viene così effettuata


40

tramite una cornice rettangolare, disegnata attraverso un foglio di stile a

cascata opportunamente codificato.

Esso viene chiamato all’interno di una pagina JSP (Java Server Page) che

permette di visualizzare l’immagine di base, con l’aggiunta però di richiami

al foglio di stile appositamente creato, che contiene il comando per

generare appropriate cornici attorno allo stato che deve essere

evidenziato.

Le pagine JSP forniscono contenuti dinamici in formato HTML, esse sono

una tecnologia Java per lo sviluppo di application server. Si basano su un

insieme di speciali tags con cui possono essere invocati funzioni predefinite

o codice Java.

All’interno del file JSP viene instanziato un oggetto della classe

processUtility, che è stata creata appositamente. Instanziare un oggetto di

questa classe infatti serve per andare a leggere un particolare file di JBPM,

il gdp.xml, che serve per descrivere i grafici dei processi mediante il

comodo formato XML. Vediamo un semplice esempio:

<?xml version="1.0" encoding="UTF-8" ?>

<process-diagram name="simple" width="469" height="438">

<node name="start" x="150" y="25" width="140" height="40">

<transition name="to_state" />

</node>

<node name="first" x="150" y="125" width="140" height="40">

<transition name="to_end" />

</node>


41

<node name="end" x="150" y="225" width="140" height="40" />

</process-diagram>

Come si può notare, questo file contiene le informazioni principali del

diagramma di flusso. Queste informazioni vengono, quindi, elaborate dalla

classe processUtility, per essere salvate all’interno di oggetti appositamente

creati, appartenenti alle due classi DiagramInfo e DiagramNodeInfo, che

contengono rispettivamente le informazioni sull’intero diagramma e sul

singolo nodo.

Queste informazioni verranno richieste, appunto, a questi oggetti nei vari

punti del file JSP e saranno, quindi, sempre disponibili per poter creare la

cornice che evidenzi il nodo in questione.

Per un esempio completo viene mostrata questa parte di codice

estrapolata dalla pagina JSP:

<%

style = "top:" + node.getY() + "px;left:" + node.getX() + "px;width:"

+ (node.getWidth() - 3) + "px;height:" + (node.getHeight() - 3)

+ "px";

styleClass = "pbox";

if (token.getEnd() != null)

styleClass = "pbox_e";

if (token.isSuspended())

styleClass = "pbox_s";

%>


42

Come si può vedere, le coordinate e le dimensioni sono prese da delle

funzioni get apposite, ottenute dalla classe DiagramNodeInfo,

successivamente viene caricata la cornice dal file CSS, di cui possiamo

vedere una porzione:

div.pbox {

border-color:#0000ff;

}

div.pbox_s {

border-color:#aa6600;

}

div.pbox_e {

border-color:#cc0000;

}

Lo stato del nodo può trovarsi in 3 situazioni distinte, e ciò si rileva

tramite una cornice di colore diverso ed una scritta sopra che

attribuiscono chiarezza alla visualizzazione. Anche questa informazione

viene prelevata, come abbiamo avuto occasione di apprezzare nel codice

della pagina JSP, tramite una funzione booleana che ritorna la situazione.

E’ possibile vederne un esempio nello screenshot seguente.


43

FIGURA 4.3

L’immagine rappresenta un nodo in stato di esecuzione, con la scritta

Running sopra e contornato da una cornice blu. Se, invece, il nodo si trova

sospeso, appare la scritta Suspended, con la cornice ocra, se è finito la

cornice è rossa e appare la scritta Ended, come possiamo vedere gli

screenshot seguenti.


44

FIGURA 4.4


45

FIGURA 4.5

Questa funzionalità è stata globalmente accettata dal team di Visionest e

verrà presto integrata nel gestionale Finanza 3000.


46

4.6 Analisi statica e dinamica

Al termine di ognuna delle fasi di sviluppo è stato verificato il codice

prodotto. Una prima verifica veniva compiuta essenzialmente tramite

analisi statica, al fine di accertare che il flusso dei vari dati fosse corretto in

ogni punto del software prodotto. Sono stati approntati, inoltre, molti test

facenti parte dell’analisi dinamica: principalmente di natura funzionale,

strutturale e di integrazione fra le componenti, in modo tale da correggere

la maggior parte degli errori. In generale, questi test non hanno sollevato

problematiche di rilievo, ed anzi, hanno dimostrato una buona affidabilità

ed una sostanziale robustezza del sistema.

Con la supervisione del tutor aziendale si è così proceduto al collaudo, che

ha dato, anche esso, esito positivo, conferendo il via libera alla messa in

produzione dello strumento.

Capitolo 5 – Consuntivo e conclusioni

47

Capitolo 5

Consuntivo e conclusioni

Questa sezione presenterà un confronto fra il tempo preventivato per

ogni attività che ha concorso alla realizzazione del progetto e quello

effettivamente impiegato; inoltre saranno presentate alcune considerazioni

personali riguardo allo svolgimento dello stage e le conclusioni tratte da

tale esperienza.

5.1 Confronto fra il preventivo ed il

consuntivo

Le attività che si sono svolte durante lo stage sono state essenzialmente

quelle preventivate inizialmente.


48

La progettazione ha richiesto più tempo rispetto a quanto preventivato

inizialmente; la fase di codifica, in compenso, è stata più breve, permettendo

di rispettare appieno i tempi di realizzazione. Dapprima, infatti, si era

cercato di intervenire sull’immagine reperita tramite la servlet, andando a

modificarla e salvarla nuovamente, per poi visualizzarla di nuovo assieme

allo stato del processo, che viene rappresentato da una sorta di cornice.

Questa operazione sarebbe stata molto delicata e la sua realizzazione

avrebbe richiesto molto tempo, al di là dell‘incremento dell‘attività della

servlet per la reinterpretazione dell‘immagine. Si è quindi deciso di

intraprendere una strada più semplice, utilizzando un semplice foglio di

stile CSS (di cui abbiamo parlato nel capitolo dedicato alla realizzazione);

ma molto più lunga per quanto ha riguardato la progettazione. Il problema

fondamentale era cercare di capire se tale soluzione si poteva adattare al

software Finanza 3000 di Visionest. Il team Visionest ha giudicato

positivamente la soluzione, ritenendola molto brillante, di facile utilizzo, e

adatta ad essere manipolata in futuro, perciò, in seguito all’approvazione, si

è proceduto alla realizzazione del progetto. Per questo motivo è stata

necessaria una progettazione più intensa e attenta ai dettagli e, quindi, sono

state riscontrate alcune discrepanze con quanto preventivato.

5.2 Diagramma di Gantt

Quanto detto in precedenza può essere esposto in maniera visiva tramite

il seguente diagramma di Gantt, che relaziona il tempo preventivato per

ogni attività, segnato in azzurro, con quello effettivamente portato a


49

consuntivo, segnato in rosso.

FIGURA 5.1


50

5.3 Analisi critica dello stage

Pur essendoci stato un buon inserimento nel team di lavoro e nel contesto

dell’azienda, l’adozione di metodologie appropriate e di nuovi strumenti

non è stata banale: molto tempo lavoro, infatti, è stato dedicato allo studio

della piattaforma. Importantissime sono state la comunicazione con il tutor

aziendale e la sua collaborazione, che hanno permesso di superare con

facilità le difficoltà iniziali e hanno realmente accelerato i tempi di

adattamento ai ritmi di lavoro aziendali. Gli obbiettivi sono stati

complessivamente raggiunti: è stata realizzata la servlet secondo le

specifiche richieste; sono stati soddisfatti anche requisiti opzionali e

desiderabili, oltre a quelli obbligatori; è stata già avviata la messa in

produzione del prodotto realizzato durante lo stage. Lo stage è stato senza

dubbio utile, in quanto ha introdotto nuovi strumenti di sviluppo e di

lavoro non inseriti nel programma di studi. La formazione fornita

dall’Università in merito alle attività svolte è risultata in diversi casi più che

sufficiente. E’ stata molto utile la dimestichezza appresa nei linguaggi

orientati ad oggetti e soprattutto nell’ambito della piattaforma Java,

acquisita durante i corsi di Programmazione 1 e di Programmazione

concorrente e distribuita. Per quanto riguarda, invece, il linguaggio XML, le

lezioni di Basi di dati 2 sono state molto importanti per capire a fondo la

sintassi usata. Il corso di Ingegneria del software ha, inoltre, fornito solide

fondamenta per lo svolgimento del progetto, soprattutto per ciò che

riguarda l’esperienza acquisita nel contesto di una realtà aziendale, nella

quale non si è più fini a se stessi ma tutti fanno parte di un progetto

comune, ognuno con compiti specifici che vanno realizzati spesso in

simbiosi. Una critica negativa può essere rivolta al programma di studi


51

universitari in quanto non ha fornito una base sufficiente per quanto

riguarda un ambito molto attuale quale Java Enterprise, gli application

server e le applicazioni web in generale, che sono molto in voga di questi

tempi, soprattutto nel campo aziendale.

Gli strumenti utilizzati in corso d’opera si sono rivelati molto utili ed

hanno rispettato le aspettative nei loro confronti, il giudizio su di essi non

può essere quindi che positivo. Trovandosi però lo stagista a confronto con

strumenti da lui a volte mai utilizzati ha avuto bisogno di un periodo di

apprendimento dei medesimi. Questo problematica non c’è stata per

quanto riguarda l’IDE Netbeans in quanto già adottata durante il corso di

ingegneria del software, ma si è rivelata soprattutto per l’uso di Apache

Maven e delle servlets in generale, due tools che non erano mai stati

utilizzati in passato.

Dal punto di vista formativo lo stage si è presentato come una esperienza

reale che è si è rivelata utile per comprendere le più generali

problematiche aziendali, quali il rispetto delle scadenze, la misura dei

risultati prodotti, la gestione del personale; il giudizio, in questo senso,

quindi, non può essere che positivo. Lo svolgimento dello stage è stato uno

dei modi migliori per introdurre lo studente nel mondo del lavoro ed è

stato foriero, sia per lo stagista, sia per l’azienda, di buoni risultati: lo

studente ha potuto apprendere nuovi linguaggi, realtà e ambienti di lavoro,

per l’azienda, invece, è stato un mezzo per raggiungere un ampliamento

delle funzionalità del proprio prodotto software e l’occasione per

conoscere una nuova personalità che in futuro potrebbe essere inserita

all’interno come dipendente. Non bisogna, infatti, scordare che l’azienda ha

approvato il lavoro dello stagista e ne ha avviato la messa in produzione

all’interno del proprio gestionale proprietario: Finanza 3000.

52

Bibliografia

[1] JBoss, http://www.jboss.com

[2] JBoss Community, http://www.jboss.org

[3] Visionest, http://www.visionest.com

[4] Wikipedia, http://www.wikipedia.org

[5] Java, http://www.java.com

[6] Maven, http://maven.apache.org

[7] BPM, http://www.bpm.com

[8] Novocode, http://www.novocode.com/doc/servlet-essentials

[9] Tecnoteca, http://www.applicationserver.it

[10] Javaportal, http://www.javaportal.it

tesi - integrazione di un’applicazione di bpm - visualizzare lo stato di un processo

Documents