Upload
danilo-tallini
View
222
Download
1
Embed Size (px)
DESCRIPTION
Anno Accademico 2009/10 Tesi di Laurea Triennale in Informatica Laureando: Andrea Alberti Relatore: Prof. Livio Colussi FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Triennale in Informatica Pagina 2 di 56
Citation preview
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 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.
Capitolo 1 – Introduzione
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à:
Capitolo 1 – Introduzione
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.
Capitolo 1 – Introduzione
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
Capitolo 1 – Introduzione
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);
Capitolo 1 – Introduzione
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
Capitolo 2 – Pianificazione delle attività
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
Capitolo 2 – Pianificazione delle attività
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.
Capitolo 2 – Pianificazione delle attività
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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.
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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;
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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.
Capitolo 3 – Analisi dei requisiti
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).
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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.
Capitolo 3 – Analisi dei requisiti
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.
Capitolo 3 – Analisi dei requisiti
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:
Capitolo 3 – Analisi dei requisiti
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
Capitolo 3 – Analisi dei requisiti
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
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
Capitolo 4 – Realizzazione
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
Capitolo 4 – Realizzazione
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
Capitolo 4 – Realizzazione
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.
Capitolo 4 – Realizzazione
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:
Capitolo 4 – Realizzazione
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.
Capitolo 4 – Realizzazione
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à è
Capitolo 4 – Realizzazione
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 è
Capitolo 4 – Realizzazione
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
Capitolo 4 – Realizzazione
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>
Capitolo 4 – Realizzazione
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";
%>
Capitolo 4 – Realizzazione
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.
Capitolo 4 – Realizzazione
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.
Capitolo 4 – Realizzazione
45
FIGURA 4.5
Questa funzionalità è stata globalmente accettata dal team di Visionest e
verrà presto integrata nel gestionale Finanza 3000.
Capitolo 4 – Realizzazione
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.
Capitolo 5 – Consuntivo e conclusioni
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
Capitolo 5 – Consuntivo e conclusioni
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
Capitolo 5 – Consuntivo e conclusioni
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