Signoretti-Tesi Specialistica

UNIVERSITÀ DEGLI STUDI DI TRIESTE
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA
REALIZZAZIONE DI UN DASHBOARD
PER IL CONTROLLO DI COMMESSE SOFTWARE
DI UN SYSTEM INTEGRATOR
LAUREANDO: RELATORE:
Alessandro SIGNORETTI Chiar.mo Prof. Marco PARENZAN
CORRELATORE:
Ing. Mauro INZERILLO
Anno Accademico 2007-2008

Sommario
1 INTRODUZIONE ...................................................................................................... 4
1.1 Motivazioni del lavoro ................................................................................... 4
1.2 Obiettivi tattici ............................................................................................... 5
1.3 Vincoli di Progetto ......................................................................................... 6
1.4 Riassunto dei capitolo seguenti ..................................................................... 7
2 ANALISI FUNZIONALE ............................................................................................. 8
2.1 Attori .............................................................................................................. 8
2.1.1 Laboratorio ............................................................................................ 8
2.1.2 Euris Solutions S.p.A. ............................................................................. 9
2.1.3 Azienda cliente ....................................................................................... 9
2.2 Definizione delle Entità ................................................................................ 10
2.2.1 Task e preventivi .................................................................................. 10
2.2.2 Gestione degli Avanzamenti ................................................................ 14
2.2.3 Dettaglio degli avanzamenti ................................................................ 18
2.2.4 Check task mancanti ............................................................................ 20
2.2.5 Dettaglio Check task mancanti ............................................................ 20
2.2.6 Check persone esterne ........................................................................ 21
2.2.7 Gestione Avanzamenti Economici ....................................................... 21
2.2.8 Dettaglio avanzamenti economici ....................................................... 24
2.2.9 Avanzamenti Commessa ...................................................................... 25
2.3 Schema concettuale delle entità ................................................................. 30
3 CASI D’USO ........................................................................................................... 31
3.1 Task .............................................................................................................. 31
3.2 Avanzamenti ................................................................................................ 33
3.3 Check task mancanti .................................................................................... 35
3.4 Check persone esterne ................................................................................ 36
3.5 Avanzamenti Economici ............................................................................... 37
3.6 Avanzamenti Commessa .............................................................................. 39
4 IMPLEMENTAZIONE ............................................................................................. 41
4.1 Software utilizzato ....................................................................................... 41
2
4.2 Architettura di sistema ................................................................................ 41
4.3 Data Layer .................................................................................................... 43
4.3.1 Tabelle.................................................................................................. 43
4.3.2 Diagramma delle relazioni ................................................................... 48
4.4 Business Logic .............................................................................................. 48
4.4.1 Viste ..................................................................................................... 49
4.4.2 Stored Procedure ................................................................................. 50
4.4.3 User-Defined Functions ....................................................................... 54
4.5 Presentation................................................................................................. 69
4.5.1 Implementazione WinForm ................................................................. 69
4.5.2 Implementazione Web Part ................................................................. 78
5 CONCLUSIONI....................................................................................................... 96
3
1 INTRODUZIONE
L’applicazione, descritta e progettata in questo lavoro, serve a
consuntivare, controllare e pubblicare i dati riguardanti i progetti di sviluppo in
corso presso il Laboratorio Euris di Trieste.
Tali progetti pongono diverse problematiche:
• Sono presenti in numero elevato e affrontati contemporaneamente

(almeno una decina ad un dato istante)
• Sono sviluppati su diverse tecnologie
• Sono affrontati con team differenti che si possono “intersecare”
• Sono gestiti in modo “Fixed Budget”, cioè fatturando al cliente la

quantità di giornate di progresso nello sviluppo di un progetto
(chiamate “avanzamento”) differenti dalle giornate effettivamente
lavorate a discrezione del capo progetto.
L’applicativo è stato, inoltre, progettato per integrarsi con diversi sistemi

aziendali, già utilizzati per diversi processi interni, come, ad esempio, il
Sistema Informativo Rapportini (SIR) per la registrazione delle presenze e la
consuntivazione del lavoro effettivamente svolto dai dipendenti.
L’utilizzo dell’applicazione è rivolto ai diversi capi progetto presenti in

azienda, i quali inseriscono dati a loro discrezione e ne possono trarre
indicazioni utili per il processo di sviluppo delle singole attività.
1.1 Motivazioni del lavoro

Non sono attualmente disponibili soluzioni di mercato, a costi sostenibili,
capaci di realizzare i casi d’uso richiesti.
L’applicativo prodotto necessita della comunicazione con diversi sistemi
aziendali già esistenti e, anche se fosse disponibile un pacchetto applicativo
pronto, il costo di un’integrazione sarebbe molto elevato, tenendo anche in
considerazione che l’attività principale dell’azienda, alla quale è rivolto questo
progetto, è proprio lo sviluppo software e la system integration.
Inoltre alcune caratteristiche richieste per la soluzione sviluppata, come,
ad esempio, la creazione di WebPart e la loro conseguente integrazione in
4
Microsoft Office Sharepoint Server 2007 (MOSS2007), non sono ancora
generalmente disponibili nel canale commerciale e non offrono complesse
funzionalità di pubblicazione dati.
Per i motivi appena descritti, sarebbe inutile affidarsi ad una soluzione

generica, non improntata sui flussi informativi tipici sui quali si basa l’azienda,
in quanto la modalità di calcolo e presentazione di parametri e indici varia tra
azienda e azienda.
In conseguenza a quanto è stato detto, si è giustificata l’utilità nello

sviluppare un’applicazione ad-hoc con funzionalità semplificate ed orientata
all’utilizzo esclusivo del Laboratorio Euris della sede di Trieste.
1.2 Obiettivi tattici

Le fasi salienti, in base alle quali sono state impostate le attività di
Analisi e Progettazione dell’applicazione, sono:
Formalizzazione dei casi d’uso con il supporto degli utenti finali

Definizione degli attori operanti sul sistema
Analisi delle entità da considerare e dei reciproci legami
Definizione dell’architettura e dei rapporti con sistemi esterni
Generazione degli schemi concettuali e logici della base dati
Progettazione delle funzionalità dei pannelli di controllo
Implementazione delle funzionalità progettate e dell’interfaccia
grafica
Test dell’applicativo di gestione della situazione produttiva con dati
di prova
Deploy del sistema con dati di produzione
Definizione di attori e relativi permessi di accesso ai dati pubblicati
Implementazione delle funzionalità dell’applicazione web
Test della WebPart con dati di prova
Messa in produzione del Web Front-end sul sito del Laboratorio
Inoltre, i punti essenziali su cui è necessario soffermarsi durante lo

svolgimento del lavoro sono i seguenti:
• Consuntivazione delle attività in maniera flessibile, in quanto ogni

cliente chiede un rendiconto diverso a seconda del tipo di attività
5
• Tracciamento e monitoraggio degli avanzamenti in relazione al lavoro
effettivo, supportati da misure calcolate di efficienza
• Trasformazione del progresso tecnico di ogni progetto in grandezza

economica
• Produzione di dati di avanzamento coerenti con le esigenze del

controllo di gestione, associare, cioè, i progetti alle commesse definite
da contratto con il cliente
• Pubblicare di dati della produzione al resto dell’azienda e al cliente in

modo regolamentato.
1.3 Vincoli di Progetto

I principali vincoli, su cui si basa l’analisi, la progettazione e il successivo
sviluppo dell’applicazione descritta in questa tesi, sono i seguenti:
• Utilizzo di tecnologie Microsoft in uso presso l’azienda, in particolare il

linguaggio di programmazione C# e la tecnologia ADO.NET,
supportati entrambi dal .NET Framework, e il prodotto Microsoft
Office Sharepoint Server 2007.
• Lo sviluppo dell’applicazione è rivolto all’utilizzo interno del

Laboratorio Euris della sede di Trieste ed è, quindi, fondato sul
processo di gestione dei progetti sul quale è già basata l’attività.
• E’ previsto, inoltre, che l’analisi del sistema sia semplificata rispetto

alla realtà, in particolare non è richiesta un’interazione diretta con il
settore commerciale dell’azienda ma vengono utilizzati diversi
parametri, statici e precalcolati, che tengono in considerazione una serie
di grandezze già aggregate e valutazioni, fornite dall’area commerciale
dell’azienda. La semplificazione è richiesta in quanto non esistono
sistemi automatizzati, che si possano interfacciare con il sistema da
sviluppare, che forniscano dati economici ad un livello di aggregazione
tale che possano essere utilizzati dal Laboratorio.
6
1.4 Riassunto dei capitolo seguenti
• Capitolo 2 – Analisi funzionale: definizione astratta di tutte le entità e
delle relazioni tra queste per ottenere le specifiche da utilizzare per
definire le funzionalità del sistema.
• Capitolo 3 – Casi d’uso: definizione dettagliata delle funzionalità

svolte dalle entità descritte e utilizzate dagli utenti finali.
• Capitolo 4 – Implementazione: sviluppo del sistema, comprensivo di

Database, client di presentazione con interfaccia grafica e WebPart,
basato su analisi e progettazione effettuate precedentemente, e
conseguente codifica.
• Capitolo 5 – Conclusioni: valutazione conclusiva del lavoro effettuato,

e descrizione degli interventi futuri di miglioramento o integrazione del
sistema.
7
2 ANALISI FUNZIONALE
L’applicazione per la gestione delle commesse software nasce
dall’esigenza di avere uno strumento informatico con il quale centralizzare i
dati tecnici ed economici dell’attività interna.
I requisiti sono stati ricavati da reali e ben definite esigenze di uno degli
utenti finali dell’intero sistema, nella fattispecie l’Ing. Mauro Inzerillo,
Responsabile Tecnico del laboratorio interno alla sede di Trieste della Euris
Solutions S.p.A.
Dall’esposizione delle problematiche reali e dei concetti specifici sui quali

si fonda l’applicazione, si è proceduto alla formalizzazione degli attori, delle
entità e delle funzionalità richieste.
L’analisi funzionale è riportata di seguito.
2.1 Attori
Gli attori sono le persone (o gruppi di persone) che hanno interesse
all’utilizzo dell’applicazione di Gestione delle Commesse Software.
Questi soggetti, in base al proprio ruolo ben definito, avranno la
possibilità di effettuare inserimenti, modifiche e cancellazioni sui dati
complessivi o visualizzare statistiche e informazioni tecniche ed economiche a
partire da essi.
Gli attori coinvolti sono i seguenti:
2.1.1 Laboratorio
Si occupa dell’effettivo sviluppo dei progetti ad esso commissionati.
I progetti richiesti possono spaziare tra reingegnerizzazione di codice a
creazione di 8apportino, tra personalizzazioni di sistemi informativi allo
sviluppo di applicativi ad hoc,
tra aggiunte di funzionalità su software già esistente a plug-in e tools per
applicativi commerciali.
8
Il Laboratorio è composto da dipendenti che lavorano principalmente
nella sede di Trieste.
E’ possibile che alla normale attività del laboratorio, collaborino in
alcuni casi anche persone esterne al laboratorio, ma comunque dipendenti della
Euris Solutions S.p.A.
2.1.2 Euris Solutions S.p.A.

Azienda informatica che stringe un rapporto d’affari con un azienda
cliente esterna per la fornitura.
Questa si occupa principalmente della negoziazione dei dettagli
economici con l’azienda cliente che richiede la fornitura di un prodotto
informatico o un servizio.
2.1.3 Azienda cliente

Azienda esterna che ha interesse a stringere un rapporto d’affari con
un’azienda informatica per ottenere un applicativo software, una integrazione o
personalizzazione per un sistema esistente o un servizio di tipo informatico
(consulenza, ecc…).
Specifiche e dettagli sul prodotto o il servizio richiesto vengono
concordati con il Laboratorio.
9
2.2 Definizione delle Entità
Le entità rappresentano i concetti astratti sui quali si basa

l’organizzazione delle attività e che consentono la gestione concreta dei
progetti sviluppati nel Laboratorio.
2.2.1 Task e preventivi

Task e preventivi sono due entità strettamente legate tra loro, in quanto
i task sono composti da uno o più preventivi, i quali rappresentano ognuno una
porzione dell’attività complessiva da svolgere per sviluppare un intero progetto
o task.
La definizione di task, preventivi e relativi attributi è riportata di seguito.
2.2.1.1 Task
I Task sono il fulcro dell’attività propria del laboratorio, in quanto
rappresentano i singoli progetti che vengono sviluppati su commissione di
aziende clienti o di altre divisioni interne a Euris Solutions S.p.A.
Ogni Task può essere sviluppato da un diverso numero di persone

fisiche, generalmente dipendenti del Laboratorio, ma, in alcuni casi, anche da
persone esterne al Laboratorio ma sempre dipendenti Euris Solutions S.p.A.
Ad ogni persona che partecipa allo sviluppo del Task può essere
attribuito un ruolo che corrisponde alla mansione che il dipendente stesso sarà
chiamato a ricoprire all’interno del singolo progetto.
Un determinato ruolo, come ad esempio “Capo Progetto” o
“Programmatore Senior”, può essere ricoperto da più persone.
Il ruolo ricoperto da una certa persona in un determinato Task è
totalmente indipendente dal ruolo che ricopre in un altro Task, quindi, ad
esempio, se un dipendente è “Analista Programmatore” in un progetto, può
tranquillamente assumere il ruolo di “Sviluppatore” in un altro.
10
2.2.1.2 Preventivo
Quando si formalizza l’accordo con un cliente per lo sviluppo di un
progetto su commissione, l’azienda informatica deve fissare per contratto un
determinato numero di giornate lavorative (ognuna composta da 8 ore ) che
rappresentano il preventivo, cioè il numero di giorni-uomo che l’azienda
informatica dichiara di impiegare per fornire il proprio prodotto “chiavi in
mano” al cliente e sulle quali il cliente stesso baserà il proprio pagamento.
Le giornate di preventivo sono importanti sia a fini economici sia a fini

operativi, in quanto rappresentano un limite di tempo sul quale il cliente fa
affidamento per ottenere il software richiesto utilizzabile.
Da quanto detto precedentemente si può comprendere quanto sia
importante che l’azienda informatica non ecceda i giorni preventivati perché,
oltre a non essere retribuiti, i giorni in eccesso provocano un danno
all’immagine dell’azienda, dunque bisogna cercare di trovare la giusta via di
mezzo tra preventivo non troppo stringente e difficoltà effettiva del lavoro.
Nel limite del possibile l’azienda dichiarerà come preventivo un

numero di giorni superiore a quelli che prevede di impiegarci effettivamente, in
modo tale da ottenere un margine di guadagno sul singolo Task.
Ciò non è sempre possibile, in quanto alcuni Task potrebbero essere
cruciali per eventuali/probabili commissioni successive per lo stesso cliente e
quindi da affrontare con maggior cura e aggiungendo funzionalità non richieste
per agevolare lo sviluppo delle componenti successive.
I singoli preventivi non sono forzatamente legati ad un unico Task, ma

questo tipo di associazione è fondata sul tipo di avanzamento selezionato per il
singolo Task.
In base al tipo di avanzamento fissato, ad un Task possono essere

associati più di un preventivo secondo la tabella seguente:
TIPO AVANZAMENTO DESCRIZIONE

Esiste un solo preventivo relativo ad
una commessa (formata da uno o più
Task di uno stesso cliente). Vengono
Commessa
considerate tutte le ore di lavoro dei
dipendenti registrate con lo stesso
codice commessa.
Esiste un preventivo per ogni ruolo
definito nella commessa. Vengono
considerate separatamente tutte le ore
Commessa figura
di lavoro dei dipendenti registrate con
lo stesso codice commessa e
appartenenti alla medesima figura.
11
Esiste un preventivo per ogni singola
persona che partecipa allo sviluppo
dei Task afferenti alla commessa.
Commessa Persona Vengono considerate separatamente
tutte le ore di lavoro svolte dallo
stesso dipendente e registrate con lo
stesso codice commessa.
Esiste un solo preventivo relativo al
Task. Vengono considerate tutte le
Task ore di lavoro dei dipendenti registrate
con lo stesso codice di Ordine di
Lavoro.
Esiste un preventivo per ogni ruolo
definito nel Task. Vengono
considerate separatamente tutte le ore
Task figura
di lavoro dei dipendenti registrate con
lo stesso codice di Ordine di Lavoro e
appartenenti alla medesima figura.
Esiste un preventivo per ogni singola
persona che partecipa allo sviluppo
del Task in oggetto. Vengono
Task persona considerate separatamente tutte le ore
di lavoro svolte dallo stesso
dipendente e registrate con lo stesso
codice di Ordine di Lavoro.
La distinzione tra singole persone, gruppi o task interi viene decisa in

sede di stipula del contratto, generalmente in base alle preferenze del cliente,
ed è fondamentale per poter garantire un livello di differenziazione preciso dei
costi in base alle persone che lavoreranno effettivamente sul progetto.
Ad esempio, una giornata lavorata da un “Analista Programmatore” sarà più
costosa di una giornata di un “Programmatore Senior”.
La differenza tra preventivo e giorni effettivamente lavorati dà il

margine di guadagno dell’azienda sul singolo Task.
2.2.1.3 Attributi di task e preventivo

Gli attributi utili per descrivere i task, i preventivi, le loro caratteristiche e il
loro legame reciproco sono i seguenti:
• Nome del Task: è un codice che identifica univocamente il task.
12
Se il tipo di avanzamento è uno tra Commessa, Commessa Figura o
Commessa Persona, il nome del task corrisponderà al codice attribuito
alla prima commessa dalla quale il task ha iniziato ad erodere le ore al
momento della definizione dell’attività di sviluppo per il cliente. Se,
invece, il tipo di avanzamento corrisponde ad uno tra Task, Task Figura
o Task Persona, il nome del task corrisponderà al nome assegnato dal
Laboratorio all’intero progetto.
• Descrizione: descrive, in modo estremamente sintetico, la tipologia

dell’attività relativa al task. Nel caso in cui il nome del task sia stato
inserito come codice commessa, questo può presentarsi sotto forma di
denominazione auto esplicativa dell’attività del progetto.
• Commessa: codice della commessa dalla quale il task sta attualmente

erodendo le giornate contrattuali ancora disponibili.
• Gruppo: denominazione dell’azienda cliente con la quale si è stretto un

rapporto contrattuale per la fornitura di un prodotto informatico o un
servizio che è identificato dal task stesso.
• Tipo di Avanzamento: rappresenta la modalità con la quale vengono

registrati i diversi preventivi afferenti al task. Da esso dipende il
numero di preventivi associati ad ogni task e il tipo di figura associata
ad ognuno di questi preventivi. La descrizione dei diversi tipi di
avanzamento è già stata affrontata precedentemente nella sezione
“preventivi”.
• Stato: ha un valore binario, definisce se il progetto relativo al task è

stato completato ed è già stato consegnato al cliente o se, invece, è
ancora in fase di sviluppo.
• Preventivo: numero delle giornate lavorative o, per essere più precisi,

dei giorni-uomo che l’azienda informatica dichiara di necessitare per
fornire il proprio prodotto completo e funzionante al cliente e sulle
quali il cliente stesso baserà il proprio pagamento. Il valore assegnato al
preventivo dipenderà dagli accordi presi in fase di definizione del
contratto con il cliente ed è riferito alla figura specificata. La somma
dei giorni di preventivo relativi ad ogni figura contemplata in un
determinato task rappresenta le giornate di preventivo associate
all’intero progetto.
13
• Figura: persona fisica o ruolo (svolto da una o più persone fisiche) ai
quali viene associato un singolo preventivo all’interno di un task. Il
livello di granularità nella definizione degli attori del task dipende dal
tipo di avanzamento. La seguente tabella di correlazione tra tipo di
avanzamento e figura esemplifica il genere di legame che intercorre tra
i due attributi:
Tipo di Avanzamento Figura

Commessa, Task Nessuna
Capo progetto, analista programmatore,
Commessa figura, Task
programmatore senior, programmatore
figura
junior, CP, AP, ecc…
Commessa persona, Task
Nome del dipendente
persona
2.2.2 Gestione degli Avanzamenti

Ogni preventivo raggruppa sotto di se le ore (o giornate) di lavoro dei
dipendenti che cooperano alla specifica attività identificata dal preventivo
stesso.
La definizione di avanzamenti e relativi attributi è riportata di seguito.
2.2.2.1 Avanzamento
L’avanzamento di un preventivo sul singolo Task in un determinato
mese è la misura di quanta parte del preventivo è attribuibile a quel mese.
L’avanzamento è legato al singolo preventivo e non direttamente al

Task del quale fanno parte i preventivi stessi.
14
Sulla base di quanto detto, l’avanzamento non è una misura reale del
lavoro effettivamente svolto dai membri del Laboratorio, ma una proiezione
dell’attività svolta sui giorni preventivati.
Dunque, mentre Task e preventivo sono una misura assoluta del lavoro
effettuato (non è influente se le ore di sviluppo complessive sono state
spalmate, ad esempio, in tre mesi piuttosto che in sei), l’avanzamento mostra lo
stato di progressione nel tempo dello sviluppo del progetto, in rapporto al
preventivo, con granularità mensile.
Le ore di avanzamento vengono decise generalmente dal capo progetto

del Task in oggetto e inserite nei mesi nei quali sono presenti ore
effettivamente spese sul medesimo Task da parte dei membri del Laboratorio.
Se il numero di ore di avanzamento inserite è superiore al numero di ore
effettivamente lavorate sul preventivo nel mese, ciò significa che è stata fatta
dell’efficienza, cioè influisce positivamente sulla possibilità di terminare il
lavoro impiegando un numero di giorni inferiori a quelli preventivati.
Viceversa, se il numero di ore inserito è inferiore al numero di ore
effettivamente lavorate sul preventivo nel mese, ciò significa che è stata fatta
inefficienza e quindi influisce negativamente sulla durata preventivata del
progetto.
2.2.2.2 Attributi di avanzamento

Gli attributi utili per gestire le attività sottese dai preventivi, le loro
caratteristiche e gli avanzamenti sono i seguenti:
• Nome del Task: codice che identifica univocamente il task.
• Descrizione: descrizione auto esplicativa del task.
• Preventivo: giornate-uomo necessarie al fine di terminare il progetto.

Ogni valore di preventivo è relativo ad una figura differente all’interno
di un task.
N.B. Nome del task, descrizione e preventivo hanno lo stesso

significato e lo stesso valore di quello descritto nella sezione “Task e
preventivi”.
• Avanzamento precedente: rappresenta la somma di tutti gli avanzamenti

mensili, relativi ad un determinato preventivo, che siano precedenti al
mese specificato. Esprime, dunque, una stima del progresso, fino al
15
mese precedente a quello considerato, nello sviluppo di un progetto, o
di una parte di esso (in base alle persone o alle figure che partecipano
all’attività del task), in rapporto alle giornate di preventivo specificate.
• Avanzamento precedente delle persone del laboratorio: ha il medesimo

significato dell’Avanzamento precedente, con la particolarità che
vengono considerate solamente le attività svolte dai membri del
laboratorio. L’avanzamento però, come già discusso, è una grandezza
stimata, non reale, e viene sempre assegnata all’intero preventivo e non
alla sola parte “destinata” ai membri del laboratorio. Per questo motivo
l’avanzamento precedente delle persone del laboratorio verrà calcolato
come “proiezione” sul valore dell’avanzamento precedente, in base al
rapporto tra le giornate di lavoro totale registrate sui 16apportino per il
preventivo determinato e le giornate di lavoro registrato da parte dei
membri del Laboratorio sullo stesso preventivo. A livello concettuale,
possiamo considerare l’avanzamento precedente delle persone del
laboratorio, come la parte (quantità) del lavoro fino ad ora svolto su un
progetto direttamente attribuibile all’attività del Laboratorio.
• Avanzamento corrente: avanzamento stimato, relativo ad un certo

preventivo, per il solo mese considerato. Esprime una stima della
quantità di lavoro svolto, nel mese considerato, sul relativo progetto, o
di una parte di esso (in base alle persone o alle figure che partecipano
all’attività del task), in rapporto alle giornate di preventivo specificate.
• Avanzamento corrente delle persone del laboratorio: ha lo stesso

significato dell’avanzamento corrente, ma differisce da quest’ultimo
perché prende in considerazione solamente il lavoro del personale del
Laboratorio. Rappresenta la “proiezione” delle giornate effettivamente
lavorate dei membri del laboratorio (sul determinato progetto e nel
mese corrente) sul valore dell’avanzamento corrente. Esprime una
stima della quantità di lavoro svolto da parte del solo Laboratorio, nel
mese considerato e sul relativo progetto (o parte di esso).
• Avanzamento totale: è la somma di tutti gli avanzamenti mensili,

relativi ad un determinato preventivo, compreso quello del mese
corrente. Viene ottenuto semplicemente sommando l’avanzamento
precedente a quello corrente per ogni preventivo appartenente ad un
progetto.
16
Esprime una stima dello stato attuale del progetto.
• Avanzamento totale delle persone del laboratorio: ha un significato

equivalente a quello dell’avanzamento totale, con l’unica differenza che
vengono prese in considerazione solamente le attività del personale del
Laboratorio. Rappresenta la “proiezione” dei giorni effettivamente
lavorati dai dipendenti del Laboratorio (sul determinato progetto e nel
mese corrente) sul valore dell’avanzamento totale. Esprime una stima
dello stato attuale del progetto per quanto riguarda la parte sviluppata
dai membri del Laboratorio.
• Giorni: numero di giornate effettivamente lavorate dagli sviluppatori,

all’interno dell’attività sottesa dal preventivo specifico, nel mese
corrente. Rappresenta il lavoro realmente svolto e registrato su ogni
progetto o parte di esso in un certo mese.
• Giorni delle persone del laboratorio: ha il medesimo significato dei

giorni, ma viene tenuta in considerazione solamente la parte di attività
svolta dai membri del Laboratorio.
• Giorni totali: quantità di giorni effettivamente lavorati dai dipendenti,

sulle attività componenti il determinato preventivo, dall’avvio del
progetto fino al mese specificato compreso. Rappresenta il lavoro
realmente svolto e registrato su ogni progetto o parte di esso fino al
mese specificato.
• Giorni totali delle persone del laboratorio: attributo che ha una valenza
simile a quella dei giorni totali, ma le attività che contribuiscono alla
somma dei giorni provengono solo dal lavoro del Laboratorio. Si può
considerare come il lavoro realmente svolto su ogni progetto, o parte di
esso, fino al mese specificato.
• A finire: valore che esprime le giornate di lavoro rimanenti, disponibili

per completare l’attività relativa al preventivo considerato, ed è ottenuto
dalla seguente differenza:
17

• Efficienza: è un rapporto che esprime la produttività delle giornate di

lavoro delle persone che collaborano allo sviluppo del progetto. Questo
indice viene calcolato col seguente rapporto:

L’efficienza può assumere i valori:
o Efficienza = 1 → il progresso nello sviluppo del progetto è

perfettamente in linea con il preventivo comunicato al cliente.
o Efficienza < 1 → il numero di giorni impiegati nello sviluppo

del progetto sono superiori a quelli preventivati e comunicati al
cliente, con un evidente spreco di risorse.
o Efficienza > 1 → il lavoro degli sviluppatori è talmente

produttivo che potrebbe consentire di ottenere un margine di
guadagno ulteriore a quello concordato da contratto con il
cliente, in quanto verrebbero pagate delle giornate di lavoro
sfruttabili, ad esempio, nello sviluppo di altri progetti.
2.2.3 Dettaglio degli avanzamenti

Ogni preventivo aggrega un certo numero di attività registrate. Per poter
avere una visione più precisa dell’evoluzione del lavoro su un determinato
preventivo può essere utile capire quali sono le singole attività che lo stanno
alimentando.
Per descrivere ogni singola attività sottesa da un preventivo, gli attributi

necessari sono i seguenti:
• Codice Ordine di Lavoro (ODL): codice univoco che identifica

un’attività, un progetto, che aggrega le ore di lavoro dei dipendenti
nelle registrazioni sul sistema SIR dei 18apportino.
18
Nel caso in cui il tipo di avanzamento del task sia task, task figura o
task persona, assume un significato equivalente al task.
• Descrizione ODL: descrizione sintetica ed auto esplicativa dell’attività

svolta all’interno dell’ODL
• Persona: nome e cognome del dipendente che ha svolto un certo

numero di ore registrate in un specifica data
• Ore: numero di ore di lavoro svolte da un certo dipendente su di un

certo ODL nella data specificata
• Data: data di registrazione della singola fase di attività giornaliera sullo

specifico ODL
• Tariffa: tariffa di mercato giornaliera della persona, cioè la quota totale,

comprensiva di tutto, che il cliente dovrà pagare per ogni giornata di
lavoro (considerate con durata di 8 ore ciascuna) svolta dal dipendente
registrato.
• Note: annotazioni sulla singola attività inerente alla registrazione
• Commessa: codice della commessa nella quale sono conteggiate lo ore

di attività registrate
• Task: nome del task al quale sottendono le attività elencate nel dettaglio
• Figura: denominazione del ruolo svolto da un certo dipendente nelle

ore di attività registrata sullo specifico preventivo del task
19
2.2.4 Check task mancanti
Il sistema in fase di progettazione e il sistema delle registrazioni delle
attività dei dipendenti, come già discusso, sono indipendenti tra loro.
Per effettuare una sorta di integrazione o, per meglio dire, fornire una
“comunicazione monodirezionale” di dati tra il sistema SIR e la Gestione delle
Commesse Software è stato instaurato un rapporto tra task (e relativi
preventivi) e attività registrate.
Mentre le registrazioni giornaliere vengono inserite “in blocco” nel
sistema, i task vengono introdotti singolarmente e manualmente nel sistema.
Può capitare che l’utente si dimentichi di creare nel sistema un task o

non abbia gli elementi necessari per fare ciò.
Questo check fornisce, appunto, un supporto utile all’utente per controllare,
in ogni momento, se ci sono delle attività registrate che non sono state
associate ad alcun task.
• Codice commessa: codice identificativo univoco della commessa che è

legato ad attività che non sono ancora state aggregate in alcun
preventivo e, conseguentemente, ad alcun task.
• Descrizione commessa: descrizione auto esplicativa della commessa
2.2.5 Dettaglio Check task mancanti

Mostra nel dettaglio le attività che non sono state ancora messe in
relazione con alcun task.
Gli attributi utili da conoscere sono quelli propri delle singole attività
registrate come “descrizione ODL”, “persona”, “figura assegnata”, “ore”, già
descritti diffusamente nel “Dettaglio avanzamenti”.
20
2.2.6 Check persone esterne
Controlla l’attività delle persone esterne al Laboratorio che hanno
partecipato allo sviluppo di task del Laboratorio.
Mostra i medesimi attributi del “Dettaglio Check task mancanti”, ma,

questa volta, riferiti ad attività di persone esterne al laboratorio su task del
laboratorio.
2.2.7 Gestione Avanzamenti Economici

Nelle precedenti sezioni sono state descritte entità, relazioni tra entità e
rispettivi attributi, riguardanti la solo attività tecnica, esponendo informazioni
su giornate lavorate, sullo stato di progresso dei progetti, sull’efficienza e
sull’influenza sui progetti del lavoro delle persone esterne al Laboratorio, cioè
dati fortemente legati al processo interno di sviluppo dei progetti.
In questa fase, denominata “Gestione degli avanzamenti economici”, si

vuole, invece, fornire una visione dell’andamento economico del lavoro sui
task, associando valori finanziari e commerciali alle singole attività tecniche
già discusse precedentemente, per ottenere indicazioni sull’impiego delle
risorse e poter quindi valutare i margini di guadagno sul singolo progetto ed
eventualmente intervenire sui task che portano inefficienza.
A differenza delle precedenti sezioni, le attività vengono aggregate per

task, in quanto è molto più interessante ed utile la visione economica
sull’intero progetto che non quella sulla singola figura o sulla singola persona.
• Nome del task: codice che identifica univocamente il task.
• Descrizione: descrizione auto esplicativa del task.
• Commessa: codice della commessa dalla quale il relativo task sta

erodendo le giornate residue ancora disponibili da contratto
21
• Gruppo: denominazione dell’azienda cliente che ha richiesto lo
sviluppo di un progetto identificato dal task.
• Giorni totali: numero di giornate realmente impiegate dai dipendenti,

fino al mese specificato, per permettere al task di progredire di stato. Si
può considerare, dunque, come il lavoro effettivo dedicato ad un
progetto fino ad una certa data.
• Giorni totali delle persone del Laboratorio: giorni totali lavorati

sull’intero task dai soli membri del Laboratorio.
• Avanzamento totale: identifica la somma degli avanzamenti mensili,

comprensivi del mese specificato, relativi ad un determinato task.
Esprime una stima, basata sul preventivo globale del task, dello stato
attuale del progetto visto dal cliente.
• Avanzamento totale delle persone del Laboratorio: porzione

dell’avanzamento totale sull’intero task attribuibile al lavoro del
personale del Laboratorio.
• Efficienza: è un indice ottenuto dal rapporto tra avanzamento totale e

giorni totali, che esprime la produttività delle giornate di lavoro delle
persone che collaborano allo sviluppo del progetto. Fornisce un
indicazione a colpo d’occhio sui task che stanno avendo un percorso di
sviluppo con efficace organizzazione e gestione di risorse e quelli che
meritano un’analisi per cercare di riportarli in linea con i preventivi.
• Costo medio: rappresenta la media del costo aziendale, relativo ad un

task, di tutti i dipendenti coinvolti nel progetto, pesato in base alle
giornate lavorate da ogni differente persona ed ai diversi costi aziendali
attribuiti ad ogni dipendente.

22
• Costo totale: è la somma dei costi aziendali, considerati sul numero di
giorni effettivamente lavorati, di ogni persona che ha collaborato allo
sviluppo del task. Rappresenta il costo sostenuto dal Laboratorio, fino
al mese considerato, del lavoro reale svolto dai dipendenti su di un
determinato task.

Con n = numero dei preventivi afferenti al task.
• Tariffa di trasferimento media: rappresenta la media delle tariffe di

trasferimento, relative ad un task, di tutti i dipendenti coinvolti nel
progetto, pesato in base alla “proiezione” sull’avanzamento del task
delle giornate realmente lavorate da ogni differente persona ed alle
diverse tariffe di trasferimento attribuite ad ogni dipendente.

• Ricavo totale di trasferimento: è la somma delle tariffe di trasferimento,

considerate sul numero di giorni di avanzamento totali inseriti, di ogni
persona che ha collaborato allo sviluppo del task. Rappresenta il costo
sostenuto dalla Euris, fino al mese considerato, per il progresso
dell’attività dei dipendenti su di un determinato task non effettiva ma
dichiarata dal Laboratorio al settore commerciale della Euris.

• Tariffa di mercato media: rappresenta la media delle tariffe di mercato,

relative ad un task, di tutti i dipendenti coinvolti nel progetto, pesato in
base alla “proiezione” sull’avanzamento del task delle giornate
realmente lavorate da ogni differente persona ed alle diverse tariffe di
mercato attribuite ad ogni dipendente.

23
• Ricavo totale di mercato: è la somma delle tariffe di mercato,
considerate sul numero di giorni di avanzamento totali inseriti, di ogni
persona che ha collaborato allo sviluppo del task. Rappresenta il costo
teoricamente sostenuto dall’azienda cliente, fino al mese considerato,
per il progresso dell’attività dei dipendenti dell’azienda informatica su
di un determinato task non effettiva ma dichiarata dal settore
commerciale della Euris all’azienda cliente.

• Tariffa media: rappresenta la media delle tariffe di mercato, relative ad

un task, di tutti i dipendenti coinvolti nel progetto, pesato in base alle
giornate realmente lavorate da ogni differente persona ed alle diverse
tariffe di mercato attribuite ad ogni dipendente.

2.2.8 Dettaglio avanzamenti economici

Lo scopo di questa sezione è quello di fornire una serie di informazioni
che offrano una visione dell’andamento economico del lavoro sui task, ma con
un livello di dettaglio maggiore rispetto a quello della precedente sezione di
“Gestione degli avanzamenti economici”.
Per raggiungere questo obiettivo verranno considerati i dati sui singoli
preventivi dei task, per poter valutare le prestazioni economiche di ogni
preventivo, separatamente dagli altri.
Gli attributi utili da conoscere sono gli stessi della sezione “Gestione
degli avanzamenti economici”, in quanto questo dettaglio rappresenta
nient’altro che gli avanzamenti economici in forma disaggregata.
24
2.2.9 Avanzamenti Commessa
Fino ad ora sono state descritte e manipolate diverse entità come, ad

esempio, task, preventivi, avanzamenti e tutte relazione instaurate tra loro. In
questo ultimo ambito, invece, si prende in considerazione il rapporto che
intercorre tra commesse, task e relativo avanzamento.
La definizione dell’entità commesse e dei relativi attributi è riportata di

seguito.
2.2.9.1 Commessa
La commessa è una componente di tipo finanziario, che non è tenuta in
considerazione dal punto di vista tecnico (il quale si basa esclusivamente sullo
sviluppo di un Task e i relativi preventivi e avanzamenti) e che quindi non
influenza l’attività del Laboratorio.
La commessa, in prima analisi, può essere vista come un contenitore di

Task.
Dal punto di vista meramente economico, il rapporto tra cliente ed

azienda informatica si fonda sull’accensione di commesse, che rappresentano
“l’interfaccia” tra chi commissiona il lavoro e l’azienda.
I Task, invece, si possono considerare come “l’interfaccia” tra azienda e

Laboratorio, in quanto, attraverso i parametri che espone, è ottenere degli
indicatori dell’efficienza delle attività del Laboratorio.
Ogni commessa può essere composta da un solo Task intero, da più

Task interi o solamente da parti di diversi Task.
Nelle seguenti tabelle vengono esposti graficamente alcuni dei possibili

scenari nei rapporti tra task e commesse da erodere.
1. In molti casi una commessa viene accesa per coprire le giornate

preventivate di un unico task, dunque si crea una corrispondenza 1:1 tra
le due entità, come si può notare dallo schema seguente:
25
Commessa → Commessa
Task → Task
Figura 2.1 – Commesse e Task 1:1
2. In alcuni casi può capitare che una commessa venga considerata come
fondo limitato dal quale diversi task possono attingere le giornate
residue disponibili, dunque si crea una corrispondenza 1:N tra le
commesse e task. Nello schema seguente è rappresentata l’eventualità
nella quale tre task erodono le giornate di un’unica commessa:
Commessa → Commessa
Task → Task 1 Task2 Task 3
Figura 2.2 – Commesse e Task 1:N
3. Nei due esempi precedenti ogni task era relazionato ad una sola
commessa. Si può verificare, invece, il caso nel quale un task erode le
giornate di avanzamento del mese considerato a due commesse
differenti, perché il residuo della prima commessa non è sufficiente a
coprire l’intero avanzamento. Se si verifica un’eventualità del genere, si
crea una corrispondenza M:N (con M che può assumere un valore
massimo di 2) tra le commesse e task. Nello schema seguente è
rappresentato un esempio del caso appena descritto, in particolare ci
sono sei differenti task che erodono le giornate di avanzamento da due
commesse, con un task che erode le giornate da entrambe le commesse:
26
Commessa → Commessa 1 Commessa 2
Task Task Task

Task → Task 1 Task 3 Task 5
2 4 6
Figura 2.3 – Commesse e Task M:N
Scendendo più nel dettaglio, si può affermare che più di un Task, o parti
di essi, possono andare ad erodere le ore concordate nella commessa, finché
queste non sono terminate e, in tal caso, sarà necessario porre in essere una
nuova commessa nel caso in cui il cliente richieda funzionalità aggiuntive.
E’ possibile e non raro, infatti, che un cliente si accordi per instaurare

commesse con un monte ore superiore al preventivo del singolo Task iniziale,
in quanto il prodotto richiesto può essere complesso e suddiviso di comune
accordo in più attività sequenziali e non parallele.
Inoltre il cliente, a lavoro ultimato, potrebbe avere interesse ad avere un
prodotto con funzionalità estese rispetto ai requisiti iniziali definiti in sede di
stipula del contratto.
Le ore relative ad una commessa possono essere erose da qualsiasi Task

attivo e relativo ad un determinato cliente e si considerano cessate quando il
residuo è pari a 0, indipendentemente dallo svolgimento dell’attività
rappresentata da ogni singolo Task.
Ogni commessa è identificata da un codice univoco, composto tramite

una codifica ben definita, che tiene in considerazione, in particolar modo, la
denominazione dell’azienda cliente.
Questa codifica è formata da un numero variabile di caratteri

alfanumerici (tra i 7 e i 9 caratteri) ed suddivisibile in due parti, come spiegato
di seguito:
o Coppia di lettere: occupano le prime due posizioni del codice, e

servono ad identificare il cliente correlato al task
o Numero progressivo: formato da una serie di cifre (tra le 5 e le

7).
27
2.2.9.2 Attributi della commessa
Durante la fase di descrizione delle commesse è stata espressa la
motivazione per la quale, in un determinato mese, l’avanzamento di un task (e
quindi il task stesso) può essere associato a due commesse differenti, quindi, in
questa fase, si descrivono gli attributi utili per la gestione manuale di questo
genere di associazione:
• Commessa: codice della commessa dalla quale il relativo task sta

erodendo le giornate residue ancora disponibili da contratto.
• Nome del task: codice che identifica univocamente il task
• Descrizione: descrizione auto esplicativa del task
• Residuo iniziale: numero di giorni residui della commessa ancora

disponibili per l’erosione da parte dei task, aggiornato al mese
precedente rispetto a quello specificato. Indica la capienza residua della
commessa al netto delle giornate già assegnate nei mesi precedenti per
coprire l’attività di altri task.
Il residuo iniziale si ottiene con la seguente formula:

• Avanzamento corrente del task: misura dell’avanzamento del task

considerato nel mese specificato
• Avanzamento scaricato: porzione dell’avanzamento corrente del task

attribuito (scaricato) sulla commessa che è attualmente legata al task
considerato.
Viene calcolato in base ad uno dei seguenti casi:
Se

allora

28
Se, invece
!

allora

• Residuo della commessa: numero di giorni residui della commessa, cioè

il residuo iniziale, al netto della quota di avanzamento scaricato sul task
attualmente legato alla commessa, nel mese specificato.
Se

allora

Se, invece
!

allora
0
• Avanzamento della seconda commessa: porzione di avanzamento

corrente del task che deve essere scaricato su una commessa differente
rispetto a quella alla quale e legato correntemente il task, in quanto il
residuo iniziale non è sufficiente a coprire il numero di giornate di
avanzamento corrente.
Se

allora la seconda commessa non viene considerata, in quanto quella

correntemente associata al task riesce a coprire tutte le giornate di
avanzamento del task stesso nel mese specificato.
Se, invece
29
allora
2.3 Schema concettuale delle entità

A fronte della definizione e descrizione delle entità appena affrontata,
riportiamo lo schema concettuale
conc Entity-Relationship
Relationship che rappresenterà il
punto di partenza per la progettazione logica.
Figura 2.4 – Schema Entity-Relationship
30
3 CASI D’USO
Nei precedenti capitoli sono state definite le entità che dovranno interagire
nel sistema finale, le relazioni tra di loro e con l’esterno del sistema e il
significato dei loro attributi.
Ora, in questa sezione di progettazione, si terranno in considerazione le

specifiche fino a qui prodotte per poter definire in maniera precisa le
funzionalità che dovrà fornire il sistema viste dal punto di vista esterno, quello
dell’utente, cioè verranno esplicitati i casi d’uso, le modalità di utilizzo del
sistema e la sua organizzazione fisica.
Questa fase dello sviluppo sarà poi il punto di partenza per

l’implementazione effettiva dell’applicazione.
3.1 Task
La sezione task riveste un ruolo di notevole importanza dal punto di vista
della manipolazione dei dati, in quanto consente di inserire, modificare e
cancellare i dati su task e preventivi, due delle entità principali dell’intero
sistema.
L’aspetto della sezione e gli attributi manipolabili seguiranno

l’impostazione del seguente schema:
Nome Codice Tipo di

Descrizione Gruppo Stato Preventivo Figura
Task Commessa avanzamento
Figura 3.1 – Sezione Task
Le operazioni possibili sui task sono le seguenti:
31
• Inserimento
o Task: è consentito l’inserimento di nuovi task, non già presenti

nel sistema. Tra i vari attributi inseribili, è possibile selezionare
il codice della commessa e il tipo avanzamento da una lista
esistente. Lo stato del nuovo task è automaticamente impostato
ad “attivo”, in quanto il questo viene considerato appena avviato
e dunque in fase di sviluppo.
o Preventivo: è possibile inserire un preventivo contestualmente

all’inserimento di un nuovo task oppure in un secondo
momento. Proprio nel momento in cui si effettua questa
operazione, il preventivo viene immediatamente posto in
relazione con il task specificato. Si possono aggiungere un
qualsiasi numero di preventivi per ogni task presente.
• Modifica
o Task: è possibile la modifica degli attributi del task, anche se

questa operazione è utile solamente nel caso in cui ci siano stati
degli errori di inserimento dello stesso. Nel normale utilizzo
dell’applicazione la modifica al task non dovrebbe essere
frequente, ed è effettuata per cambiare lo stato del task o per
modificare la sua descrizione.
o Preventivo: è consentita la modifica degli attributi del

preventivo, anche se, generalmente sia il numero di giorni di
preventivo che la figura vengono determinate in fase di
accensione del preventivo in accordo con il cliente.
• Cancellazione
o Task: è possibile eliminare in maniera diretta un task solamente

a patto che quest’ultimo non sia relazionato ad alcun preventivo.
Se un task sottende uno o più preventivi è necessario eliminare
prima questi ultimi e, quando verrà cancellato anche l’ultimo, il
task sarà eliminato automaticamente.
32
o Preventivo: in questa sezione viene consentita la cancellazione
dei preventivi. Questa operazione permette la rimozione fisica
di quest’entità dai dati del sistema e dunque spezza il legame tra
questa e il relativo task. Se il preventivo eliminato in questa
maniera è l’unico ancora legato ad un certo task, anche
quest’ultimo viene cancellato dal sistema.
• Visualizzazione
o Modalità: in questa sezione viene visualizzata la lista completa

dei preventivi esistenti, con i relativi dati, e i task ad essi
associati.
o Filtri: alla lista dei preventivi vengono applicati due tipi di filtri
Stato: permette di vedere i soli preventivi “attivi”, o

solamente gli “inattivi” o tutti, indipendentemente dal
fatto che i relativi task siano o meno terminati.
Gruppo: consente di visualizzare i soli preventivi

associati al cliente selezionato, altrimenti è possibile
visualizzare l’intera lista dei preventivi.
o Ordinamento: basato sull’ordine alfabetico, crescente o

decrescente, del nome del task.
3.2 Avanzamenti
La sezione avanzamenti offre una vasta visione sull’attività tecnica
dell’azienda informatica ed, in particolar modo, consente la gestione attiva dei
dati riguardanti l’avanzamento, cioè il valore che identifica il progresso
temporale del task.
L’aspetto della sezione e gli attributi manipolabili seguiranno

l’impostazione del seguente schema:
33
Giorni
Nome Ava Ava totale Giorni totali A Ava
Descr Preventivo Ava Giorni Efficienza
Task totale persone Lab totali persone finire prec
Lab
Figura 3.2 – Sezione Avanzamenti
Le operazioni possibili sugli avanzamenti correnti sono le seguenti:
• Inserimento: si può inserire un valore di avanzamento, riferito al

mese selezionato, in corrispondenza di ogni preventivo. Se un task non
ha preventivi associati non può essere avanzato.
• Modifica: è possibile modificare un valore di avanzamento corrente

precedentemente inserito, riferito ad un determinato mese e ad un certo
preventivo.
• Visualizzazione
o Modalità: come per la sezione dei Task, viene visualizzata la
lista completa dei preventivi esistenti e i task ad essi associati.
In questo caso, però, le informazioni offerte provengono
dall’aggregazione dei dati locali su task e preventivi con le
attività provenienti da una sorgente dati esterna.
o Dettaglio Avanzamenti: consente di visualizzare, per lo

specifico preventivo selezionato, i dati relativi alle attività
sottese dal preventivo stesso, sul modello dello schema
seguente:
Codice Descrizione
Ore Task Tariffa Data Persona Note Commessa Figura
ODL ODL
Figura 3.3 – Sezione Dettaglio Avanzamenti
34
o Filtri: alla lista dei preventivi vengono applicati tre tipi di filtri
Data: la lista dei preventivi viene visualizzata

completamente, ma i dati mostrati sono riferiti, di volta
in volta, ad un mese differente. La data del filtro si
riferisce al mese selezionato, non al giorno in
particolare.



decrescente, del nome del task.
3.3 Check task mancanti

La sezione check task mancanti mostra la lista delle commesse che
sottendono attività che non sono state messe in relazione con alcun task.
L’aspetto della sezione seguirà l’impostazione del seguente schema:
Codice commessa Descrizione commessa
Figura 3.4 – Sezione Check task mancanti
Le operazioni possibili sul check dei task mancanti sono le seguenti:
• Visualizzazione
o Modalità: viene visualizzata la lista delle commesse alle quali
sono associate attività registrate, provenienti da una sorgente
dati esterna, che richiedono l’inserimento di un task che le possa
aggregare.
35
o Dettaglio Check task mancanti: consente di visualizzare, per la
specifica commessa selezionata, i dati relativi alle attività
sottese dal commessa stessa, sul modello dello schema
seguente:
Codice Descrizione Descrizione

Persona Figura Ore Tariffa Data Note
commessa commessa ODL
Figura 3.5 – Sezione Dettaglio Check task mancanti
o Filtri: alla lista delle commesse viene applicato solamente un

tipo di filtro
Data: in base al mese selezionato, viene mostrata la lista

delle commesse che contengono attività registrate in
quel determinato mese che non hanno relazioni con
alcun task. La data del filtro si riferisce al mese
selezionato, non al giorno in particolare.

decrescente, del codice della commesse o della sua descrizione.
3.4 Check persone esterne

La sezione check persone esterne mostra la lista delle attività registrate
delle persone esterne al laboratorio le quali hanno partecipato attivamente allo
sviluppo dei progetti del laboratorio.
Codice Descrizione Descrizione

Persona Figura Ore Tariffa Data Note
commessa commessa ODL
Figura 3.6 – Sezione Check persone esterne
36
Le operazioni possibili sul check delle persone esterne sono le seguenti:
• Visualizzazione
o Modalità: viene visualizzata la lista delle attività lavorative
registrate, provenienti da una sorgente dati esterna, che
riguardano dipendenti non appartenenti al laboratorio, i quali
hanno contribuito con un certo numero di giornate lavorative
allo sviluppo di task.
o Filtri: alla lista delle attività viene applicato solamente un tipo

di filtro
Data: in base al mese selezionato, viene mostrata la lista

delle attività registrate in quel determinato mese relative
a persone che hanno collaborato nello sviluppo di task
del laboratorio. La data del filtro si riferisce al mese
3.5 Avanzamenti Economici

La sezione avanzamenti economici offre una vasta visione su parte
dell’attività tecnica (già fornita peraltro dalla sezione “Avanzamenti”) e si
focalizza sulla fornitura di informazioni economico-commerciali riguardanti i
singoli progetti dell’azienda informatica.
Questa visualizzazione offre un “colpo d’occhio” sull’efficienza

economica del lavoro del laboratorio, cioè permette di vedere tutta la lista dei
progetti e, per ognuna di esse i valori tecnici di giornate lavorate, preventivi e
avanzamenti, proiettate su valori economici di costi e tariffe dei singoli
dipendenti.
Naturalmente, per un’analisi più precisa delle dinamiche non prettamente

tecniche dell’attività, sarà necessario utilizzare altri strumenti che agiscono su
una maggior quantità di dati e con logiche differenti.
37
Ricavo
Sezione Tariffa di Ricavo Tariffa di
Costo Costo totale Tariffa
Commessa trasf. totale mercato
Avanzamenti medio totale di media
media di trasf. media
mercato
Figura 3.7 – Sezione Avanzamenti economici
Le operazioni possibili sugli avanzamenti economici sono le seguenti:
• Visualizzazione
o Modalità: a differenza della sezione degli Avanzamenti, viene
visualizzata la lista completa dei task che aggregano tutti i
preventivi esistenti. Inoltre vengono fornite, in aggiunta ai dati
tecnici degli avanzamenti, informazioni di tipo economico sui
singoli task, come è stato riportato nello schema precedente.
o Dettaglio Avanzamenti Economici: consente di visualizzare, per

lo specifico task selezionato, tutti i preventivi appartenenti al
task con tutti i dati relativi al progresso tecnico ed economico
del singolo preventivo, sul modello dello schema precedente,
ma riferito ai preventivi e non ai task.
o Filtri: alla lista dei preventivi vengono applicati tre tipi di filtri
Data: la lista dei task viene visualizzata completamente,

ma i dati mostrati sono riferiti, di volta in volta, ad un
mese differente. La data del filtro si riferisce al mese

o Ordinamento: basato sull’ordine alfabetico, crescente o decrescente, di

ogni attributo.
38
3.6 Avanzamenti Commessa
L’obiettivo della sezione avanzamenti delle commesse è quello di gestire
manualmente il rapporto che intercorre tra commesse, task e relativi
avanzamenti.
In base ad una procedura ben precisa, che verrà descritta successivamente,

è possibile assegnare, operando una scelta guidata dal processo di erosione, le
giornate di avanzamento di ogni task avanzato nel mese selezionato, stabilite
nelle sezioni precedenti, ad un massimo di due commesse differenti.
Questo processo viene definito “Erosione” delle commesse e si compone di
due fasi successive:
1. Visualizzazione dei task: in base ad un mese selezionato, viene

riportata la lista dei task che hanno subito avanzamento nel mese stesso.
Avanzamento
Residuo Avanzamento Avanzamento Residuo
Commessa Task Descrizione seconda
Commessa Corrente Scaricato Commessa
commessa
Figura 3.8 – Sezione Avanzamenti commessa
Ogni task è inizialmente associato ad una commessa e, per ognuna di

esse, è necessario conoscere il residuo di giornate disponibile.
a) per ogni commessa, vengono sommati tutti gli avanzamenti

precedenti, già spalmati in precedenza sui task, che hanno eroso
una parte di giornate disponibili. Sottraendo il valore di giorni
ottenuto al preventivo iniziale dei giorni commessa si ottiene il
residuo commessa attuale
b) comincio l’erosione del mese considerato sulle commesse

attualmente legate ai task. Viene fissato un ordine tra i task di
ogni commessa, nel caso specifico si sfrutta l’ordine di
visualizzazione dei task sulla tabella.
Per ogni task, seguendo l’ordine, si erode la commessa
utilizzando le formule per l’avanzamento scaricato e per il
residuo della commessa già descritte in fase di analisi. Se
l’avanzamento corrente è superiore al residuo iniziale della
commessa, viene specificata la quantità di giornate in eccesso
39
alla disponibilità della commessa. Questo valore dovrà essere
associato manualmente ad un’altra commessa avente
disponibilità residua di giornate superiore allo 0.
2. Proposta, eventuale, della seconda commessa: per tutti i task che

necessitano di distribuire il carico eccedente di giornate di avanzamento
su una seconda commessa, se ce ne sono, si utilizza una sezione il cui
aspetto seguirà l’impostazione del seguente schema:
Commesse Residuo
Task Residuo
con capienza commessa
Figura 3.9 – Sezione Proponi commessa
Ogni task con avanzamento eccedente visualizzato deve essere

associato manualmente ad una commesse con residuo di giornate
disponibili sufficiente (superiore o uguale alle giornate ancora da
erodere).
a) per ogni task, in ordine di visualizzazione, si seleziona da una

lista predefinita una commessa. La lista delle commesse
selezionabile per ogni singolo task è composta dalle sole
commesse accese dal cliente associato al task e che abbiano un
residuo disponibile sufficiente a coprire l’avanzamento in
eccesso alla prima commessa.
b) la commessa selezionata viene posta in relazione con il task e

viene calcolato il residuo della commessa sottraendo alla
capienza iniziale la quota di avanzamento ancora da erodere del
task.
40
4 IMPLEMENTAZIONE
Nel capitolo precedente è stato progettato, in maniera dettagliata, il
comportamento globale del sistema e la definizione dei casi d’uso, cioè le
funzionalità proprie dell’applicazione e le modalità tipiche di utilizzo delle
stesse.
Ora verranno passati in rassegna i dettagli implementativi delle parti

fondamentali del sistema, per spiegare più nel dettaglio l’organizzazione del
Database e come è stato sviluppato il codice della parte applicativa, la quale si
occupa di presentare i dati, estratti dal Database, all’utente.
4.1 Software utilizzato

Basandosi sulle specifiche iniziali, sono stati scelti, anche per Vincoli di
Progetto, i seguenti linguaggi:
• C#: linguaggio di programmazione per il codice WinForm, la gestione

delle strutture dati e lo sviluppo di WebPart.
• SQL: linguaggio di programmazione per interrogazioni su Database.
Per rendere più agevole lo sviluppo del progetto, sono stati utilizzati i
seguenti ambienti di sviluppo:
• Microsoft Visual Studio .NET 2005 con Framework .NET 2.0
• Microsoft SQL Server 2005
• Microsoft Office Sharepoint Server 2007
4.2 Architettura di sistema

Il sistema in fase di progettazione si baserà su un’architettura Three-Tier
che dovrà interagire con una sorgente dati esterna (i dati delle attività
41
giornaliere
liere dei dipendenti dell’azienda informatica) e con l’inserimento e la
manipolazione dei dati da parte degli utenti.
L’architettura definita può essere espressa graficamente come nello

schema seguente:
Figura 4.1 – Architettura di Sistema
42
Le componenti del sistema sono rapidamente descritte di seguito:
• Database del personale: sorgente dati contenente tutte le informazioni

sull’attività giornaliera dei dipendenti dell’azienda informatica.
• Utente: inserisce e manipola, tramite l’applicativo in fase di

progettazione, i dati tecnici ed economici dell’attività dell’azienda
informatica.
• Architettura Three-Tier
o Database del sistema: collezione centralizzata di dati aziendali.

Contiene dati provenienti sia da sorgenti esterne (database del
personale) che inseriti manualmente dagli utenti del sistema.
o Business Logic: strato software che comprende le logiche di

elaborazione e aggregazione dei dati del database di sistema, per
offrire alla componente di presentazione informazioni
complesse.
o Client di Presentazione: pannelli di presentazione user-friendly

che consentono la presentazione di porzioni di dati aziendali in
viste differenti. Consente, inoltre, l’inserimento, la modifica e la
cancellazione in modo logico e controllato, per evitare la perdita
o l’inconsistenza dei dati sul database di sistema.
4.3 Data Layer

Il Data Layer dell’architettura è implementato mediante le seguenti
tabelle e relazioni.
4.3.1 Tabelle
43
Task
Allows
Attributi Tipo Size Chiave Descrizione
null
Identificativo univoco
IdTask int false PK
task
Denominazione del
Task nchar 100 false
Task
Descrizione estesa
Descrizione nchar 100 true
del Task
Commessa dalla
quale il Task
Commessa nchar 20 true
sta erodendo le
giornate
FK su
Tipo di avanzamento
Tipo
TipoAvanzamento int false determinato
Avanzame
per il Task
nto
Stato di attività del
Stato bit false
Task
Data di inizio attività
DataInizioTask datetime true
sul Task
Denominazione
Gruppo nchar 30 true
dell'azienda cliente
Preventivi
Allows
null
IdPreventivi int false PK Identificativo univoco preventivo
Breve descrizione del gruppo, della
Figura nchar 70 true figura o della singola persona a cui si
riferisce il preventivo
Numero di giornate di preventivo
sulla commessa, il task, la figura o la
Preventivo float true
persona in base al tipo di
avanzamento previsto
FK su
IdTask int false Task al quale afferisce il preventivo
Task
44
Avanzamenti
Allows
null
IdAvanzamento int false PK
avanzamento
Mese int false Mese avanzamento
Anno int false Anno avanzamento
Numero di giornate di
Avanzamento float true
avanzamento mensile
FK su
IdPreventivi int false
Preventivi
Codice della 1° commessa sulla
quale viene spalmato
commessa1 nchar 20 true
l'avanzamento mensile del
preventivo
avanzamento
avaComm1 float true
mensile spalmate sulla 1°
commessa
Codice dell'eventuale 2°
commessa
commessa2 nchar 20 true sulla quale viene spalmato
l'avanzamento mensile del
preventivo
avanzamento
avaComm2 float true
mensile spalmate sull'eventuale
2° commessa
TipoAvanzamento
Allows
null
Identificativo univoco tipo
ID_tipo int false PK
di avanzamento
Denominazione del tipo
tipo nchar 40 true
di avanzamento
Descrizione estesa del tipo
descrizione nchar 100 true
di avanzamento
45
Persone
La tabella Persone contiene la lista di tutti dipendenti (membri del
laboratorio o altri dipendenti Euris) che hanno collaborato attivamente
all’avanzamento tecnico dei Task.
Allows
null
id_persona int false PK
persona
cognome nchar 40 false Cognome della persona
nome nchar 30 false Nome della persona
Data a decorrere della
quale sono in
dataInizioValidita datetime false vigore il Costo Aziendale
e la Tariffa di
Trasferimento specificati
Costo giornaliero della
persona sostenuto
costoAziendale money false
dal Laboratorio per
attività del Laboratorio
Costo giornaliero della
persona sostenuto
tariffaTrasferimento money true dalla Euris, per attività
interne o esterne al
Laboratorio
Determina se una
persona è membro
personaLaboratorioTS bit false
o meno del Laboratorio
di Trieste
Commesse
Allows
null
Codice identificativo univoco
commessa nchar 20 false PK
alfanumerico della commessa
Numero totale delle giornate
preventivoGG real false
attribuite alla commessa
46
T_AttivitaConFigura
Contiene tutti i dati sulle attività giornaliere dei dipendenti Euris.
Attraverso un applicativo di gestione centralizzato delle attività del
personale, i dati inseriti da ogni singolo dipendente Euris sul lavoro svolto,
vengono inseriti nel Database SIR (Sistema Integrato Rapportini).
Il sistema in oggetto di tesi è stato, però, svincolato dal sistema dei
Rapportini, in quanto è nato per essere utilizzato solamente all’interno del
Laboratorio e dunque non integrato in altri sistemi.
Per estrarre i dati sulle attività dei dipendenti, nelle quali saranno
presenti anche quelle dei membri del Laboratorio, è stato dunque necessario
creare questa tabella di attività che viene alimentata in modo semi-automatico
tramite una Stored Procedure che importa tutte le attività fino alla data attuale.
Dato che per tutto il sistema è stata prevista una granularità di dati
mensile è sufficiente ripetere questa operazione a cadenza mensile.
Ordine di lavoro (ODL): rappresenta un progetto sul quale lavorano uno o più
sviluppatori. Ha un codice identificativo (codice_odl) e una descrizione
(Dsc_old) che, in molti casi, corrisponde al nome del Task.
Allows
null
id int false PK
dipendente
Cognome nvarchar 50 false Cognome del dipendente
Nome nvarchar 50 false Nome del dipendente
Ore effettivamente lavorate
Ore_Durata real false
sull'attività specificata
Data di svolgimento
Data datetime false
dell'attività
Descrizione estesa
Dsc_odl nvarchar 50 true
dell'Ordine di Lavoro
Note nvarchar 200 true Note eventuali
Codice univoco della
Codice_commessa nvarchar 20 false
commessa
dsc_commessa nvarchar 50 true Descrizione della commessa
Codice univoco dell'Ordine di
codice_odl nvarchar 20 false
Lavoro
Tariffa di mercato del
dipendente, è il costo
Tariffa money true
sostenuto dal cliente per
ogni sua giornata di lavoro
Figura assegnata al
FiguraAssegnata nvarchar 80 true
dipendente
Gruppo interno all'Euris al
TipoOrdineLavoro nvarchar 8 true quale appartiene il
dipendente
47
4.3.2 Diagramma delle relazioni
Figura 4.2 – Diagramma delle relazioni
4.4 Business Logic

La Business Logic dell’architettura comprende le logiche di
manipolazione dei dati, forniti dal Data Layer descritto in precedenza, ed è
implementata mediante viste, stored procedure e user-defined functions, che
vengono descritte di seguito.
48
4.4.1 Viste
• TaskEstesiVS
Lista dei preventivi correlati ai Task.
Figura 4.3 – Vista TaskEstesiVS
SELECT
dbo.Task.IdTask, dbo.Task.Task, dbo.Task.Descrizione,
dbo.Task.Commessa, dbo.TipoAvanzamento.tipo AS
TipoAvanzamento,
dbo.Task.Stato, dbo.Task.DataInizioTask,
dbo.Task.Gruppo,
dbo.Preventivi.IdPreventivi, dbo.Preventivi.Figura,
dbo.Preventivi.Preventivo
FROM
dbo.Task
INNER JOIN
dbo.TipoAvanzamento
ON dbo.Task.TipoAvanzamento =
dbo.TipoAvanzamento.ID_tipo
LEFT OUTER JOIN
dbo.Preventivi
ON dbo.Task.IdTask = dbo.Preventivi.IdTask
49
• CommesseConAvanzamentiCorrenti
Lista delle commesse con relative giornate di preventivo.
• PersoneConTariffe
Lista dei dipendenti Euris che hanno svolto almeno qualche ora
di attività all’interno di progetti del Laboratorio.
• PersoneLAB
Lista dei dipendenti del Laboratorio Euris della sede di Trieste.
Vengono riportati costo aziendale e tariffa di trasferimento dei
dipendenti e la data di inizio validità di questi valori.
4.4.2 Stored Procedure
• InsertTaskPreventivi
Inserisce nel DB un nuovo Task con relativo codice,
descrizione, preventivo, figura, gruppo, tipo di avanzamento e
commessa alla quale alla quale erode correntemente i giorni.
Se è già stato inserito un Task con il medesimo codice, verrà

inserito solamente il preventivo specificato ed i dati relativi ad esso.
Il nuovo Task può essere inserito anche senza essere collegato

ad un preventivo, in quanto questa operazione si può effettuare in un
secondo momento.
50
• UpdateTaskPreventivi
Effettua la modifica dei dati di un Task e l’eventuale
l’eventuale preventivo
specificato.
Se per il Task da modificare non è stato specificato alcun

preventivo, quest ultimo viene inserito nella lista dei preventivi e
collegato al Task modificato.
• DeleteTaskPreventivi
Elimina il preventivo specificato contestualmente
contestualmente a tutti gli
avanzamenti che sottendono ad esso.
Se il preventivo eliminato era l’unico in relazione con un certo
Task, anche quest ultimo viene eliminato.
• UpdateAvanzamenti
Effettua la modifica del valore in giornate dell’avanzamento
connesso
nesso ad un preventivo nella data specificata.
Se non esiste un avanzamento relativo al determinato
preventivo, con mese e anno specificati, allora viene inserito come
nuovo avanzamento.
• UpdateAvanzamentiCommessa
Per ogni preventivo che ha subito

subito avanzamento in un
determinato mese, relativi al Task specificato, vengono suddivise le
giornate di avanzamento contabilizzate tra le commesse alle quali il task
51
fa riferimento, cioè viene effettuata la “spalmatura” delle giornate
disponibili della commesse sugli avanzamenti del task collegato.
La spalmatura degli avanzamenti dei Task sulle commesse è

effettuata singolarmente sui task e non su ogni singolo avanzamento dei
preventivi associati, relativi alla data specificata.
Per questo motivo è necessario utilizzare un metodo per
suddividere le giornate commessa attribuite ad un Task in modo da
assegnarle in modo coerente ai vari avanzamenti appartenenti ai
preventivi del task.
Inoltre le giornate di avanzamento di ogni singolo task, possono

essere attribuite ad un minimo di una commessa (commessa1, inserita
nella tabella dei task) e, se queste eccedono le giornate residue della
commessa1, ad un massimo di due (considerando anche la commessa2,
che diventerà poi la nuova commessa di riferimento per il task).
Il criterio di suddivisione scelto è quello di assegnare ad ogni

avanzamento una porzione di giornate dell’avanzamento corrente del
task scaricato sulla prima commessa in base al rapporto tra il numero di
giorni avanzati di ogni avanzamento e la somma totale dei giorni
avanzati del task nel mese specificato.
Si utilizza la seguente formula:

% @
&
@
$
Dove:
• Avanzamento: giornate di avanzamento di un singolo

preventivo del task in un certo mese
• @AvaTask: somma degli avanzamenti di tutti i preventivi del

task in un certo mese
• @AvaScaricato: porzione di @AvaTask assegnata ad una delle

due commesse
Questo metodo viene utilizzato per erodere le giornate di

entrambe le commesse, nel caso in cui venga specificata anche un
spalmatura della seconda commessa.
Il codice della Stored Procedure è il seguente:
52
ALTER PROCEDURE [dbo].[UpdateAvanzamentiCommessa]
@datacorrente Datetime,
@avaScaricato float,
@commessa2 nvarchar(20),
@ava2 float,
@idTask int
AS
BEGIN
DECLARE @avaTask float;

SET @avaTask = (
SELECT SUM(Avanzamento)
FROM AvanzamentiCorrentiTask(
@datacorrente, @idTask));
UPDATE dbo.Avanzamenti
SET commessa1 = AvanzamentiTask.Commessa,
avaComm1 = AvanzamentiTask.ava1,
commessa2 = @commessa2,
avaComm2 = AvanzamentiTask.ava2
FROM
(
SELECT Avanzamento, IdAvanzamento,
Commessa,
((Avanzamento/@AvaTask)*@AvaScaricato)
AS ava1,@commessa2 AS Commessa2,
((Avanzamento/@AvaTask)*@ava2) AS
ava2,@AvaScaricato AS avaScaricato,
@avaTask AS avatotaledeltask
FROM AvanzamentiCorrentiTask(
@datacorrente, @idTask)
) AS AvanzamentiTask
WHERE
dbo.Avanzamenti.IdAvanzamento =
AvanzamentiTask.IdAvanzamento;
END
• AnnullaAvanzamentiCommessa
Annulla le spalmature effettuate sugli avanzamenti appartenenti
al task specificato, in un certo mese, e ritorna il codice della commessa
che era correlata al task prima della spalmatura.
53
• UpdateTaskCommessa
UpdateTaskC
Sostituisce la commessa precedentemente collegata al Task con
quella specificata.
• ImportDatiDaSIR
Procedura che prende tutti i dati sulle attività dei dipendenti
Euris e le inserisce nella tabella T_AttivitaConFigura.
4.4.3 User
User-Defined Functions
Defined Functions
Le User-Defined Function possono essere suddivise in gruppi che
rappresentano le diverse funzionalità dell’applicativo di gestione delle
commesse.
4.4.3.1 Task
ask
• TaskEstesiGrouped
Visualizza la lista dei Task filtrata per il gruppo specificato.
54
4.4.3.2 Consuntivi
onsuntivi avanzamenti
• ConsuntiviDaAConTotali
Funzione riassuntiva che pone in join i task (TaskEstesiVS) con

i relativi dati delle attività (giorni effettivamente lavorati, distinti tra
quelli attribuibili ai membri del laboratorio e quelli
quelli attribuibili ad altri
dipendenti, ) del mese corrente e globali fino al mese precendente e gli
avanzamenti fino al mese precedente e del mese corrente (se è già stato
inserito).
I dati ottenuti vengono filtrati per gruppo, cioè per il cliente

specificato.
ato.
55
• TaskEstesiAttivitaDaA
Aggrega per preventivo tutte le attività in join con esso, in modo
tale da ottenere, per ogni preventivo, la somma delle ore delle attività
che sottende trasformata in giorni lavorati.
Le attività considerate sono quelle con data appartenente

all’intervallo specificato.
• TaskEstesiAttivitaTotali
Prima aggrega le attività per preventivo e per persona,
sommando le ore lavorate e trasformandole in giorni (in questo modo
vengono anche distinti il numero di giorni lavorati da membri del
laboratorio su un certo preventivo) e successivamente aggrega le attività
solo per preventivo e non più per persona, ottenendo la lista dei
preventivi e il rispettivo numero di giorni effettivamente lavorato totale
e i giorni lavorati solamente dai membri del laboratorio.
• TaskEstesiAttivitaNoGroupDaA
Ogni singola attività dei rapportini viene posta in join con un
certo preventivo solamente previo confronto tra valori selezionati sulla
base del tipo di avanzamento del task (ad esempio “nome del task” della
vista TaskEstesiVS e “descrizione dell’ODL” dalla tabella dei dati delle
attività nel caso in cui il tipo avanzamento sia “task”).
Se il confronto dà esito positivo allora viene effettuata la join tra

preventivo e attività, altrimenti non accade nulla.

Il codice SQL della funzione è il seguente:
56
ALTER FUNCTION [dbo].[TaskEstesiAttivitaNoGroupDaA]
(
@datainizio Datetime,
@datafine Datetime
)
RETURNS TABLE
AS
RETURN
(
SELECT
dbo.TaskAttivitaGroupByCopia(
dbo.TaskEstesiVS.TipoAvanzamento,
dbo.TaskEstesiVS.Task,
dbo.TaskEstesiVS.Figura, NULL, NULL, NULL)
AS CampoPerJoinTaskEstesi,
dbo.TaskAttivitaGroupBy(
dbo.TaskEstesiVS.Figura,
dbo.DatiPresenzeDaA.Note,
dbo.DatiPresenzeDaA.Codice_commessa,
dbo.DatiPresenzeDaA.Dsc_odl)
AS CampoPerGroupBy,
dbo.DatiPresenzeDaA.Dsc_odl,
dbo.DatiPresenzeDaA.Ore_Durata,
dbo.DatiPresenzeDaA.Tariffa,
dbo.DatiPresenzeDaA.Data,
dbo.DatiPresenzeDaA.Cognome,
dbo.DatiPresenzeDaA.Nome,
dbo.DatiPresenzeDaA.Note,
dbo.DatiPresenzeDaA.FiguraAssegnata,
dbo.DatiPresenzeDaA.id,
dbo.DatiPresenzeDaA.codice_odl
FROM
dbo.TaskEstesiVS
LEFT OUTER JOIN
dbo.DatiPresenzeDaA(@datainizio, @datafine)
ON
dbo.JoinTaskAttivita(
dbo.DatiPresenzeDaA.Dsc_odl,
dbo.TaskEstesiVS.Figura,
dbo.DatiPresenzeDaA.FiguraAssegnata,
dbo.DatiPresenzeDaA.Cognome,
dbo.DatiPresenzeDaA.Nome) = 1
)
57
• TaskEstesiAttivitaNoGroupTotali
Le attività considerate sono quelle con data fino a quello
specificata.
• TaskAttivitaGroupBy (Scalar Function)

In base al tipo di avanzamento del task, ritorna una stringa che
rappresenta il valore con il quale si aggregheranno le attività già in join
con i rispettivi preventivi.
Esiste una versione “Copia” in quanto non è possibile

richiamare la stessa scalar function 2 volte nella stessa User-defined
Function.
• JoinTaskAttivita (Scalar Function)

Consente di effettuare una join “dinamica”. Effettua un
confronto tra valori selezionati in base al tipo di avanzamento del task
specificato. Se il contronto dà esito positivo allora ritorna il valore 1,
altrimenti 0.
• AvanzamentiCorrentiETotali
Lista di tutti i preventivi e, per ognuno, la somma di tutti i suoi
avanzamenti mensili, compreso il mese corrente
• AvanzamentiTotali
Lista di tutti i preventivi e, per ognuno, la somma di tutti i suoi
avanzamenti mensili, escluso quello del mese corrente.
58
• AvanzamentoCorrente
Lista di tutti i preventivi e, per ognuno, il suo avanzamento nel
mese corrente.
corrente
• DatiPresenzeDaA
Ritorna
itorna tutti i dati dei rapportini (attività giornaliere dei
dipendenti) tra 2 date.
date
• DatiPresenzeTotali
Ritorna
itorna tutti i dati dei rapportini (attività giornaliere dei
dipendenti) dall'inizio fino alla data specificata (trova anche
anch la data
iniziale del task più vecchio).
vecchio)
• DettaglioCampoPerGroupBy
Ritorna
itorna la lista delle attività da rapportino che sottendono
sotte al
preventivo specificato.
59
4.4.3.3 Avanzamenti
vanzamenti economici
• ConsuntiviPerTaskGroupBy
Aggrega
ggrega i preventivi dei "Consuntivi"
" per Task.
• ConsuntiviConAvaTot
Effettua il join tra i dati dei Consuntivi, aggregati per
preventivo, e i dati economici (costo aziendale, tariffa di trasferimento),
anch’essi aggregati per preventivo.
Fornisce, in questo modo, per ogni preventivo,

preventivo, tutti i valori di
avanzamento, preventivo, giorni lavorati provenienti dai Consuntivi e i
valori medi e totali di costo aziendale, tariffa di trasferimento e tariffa
di mercato, ottenuti dalla semplice divisione dei valori economici totali
per i giorni
orni effettivamente lavorati sullo stesso preventivo.
• ConsuntiviConEfficienzaAvaOGiorni
Fornisce, per ogni preventivo, tutti i valori di avanzamento (se
non è stato inserito alcun valore di avanzamento si prende in
considerazione il totale dei giorni effettivamente
effettivamente lavorati), preventivo,
giorni lavorati, i valori totali di costo aziendale, tariffa di trasferimento
e tariffa di mercato e i relativi valori medi, ottenuti semplicemente
effettuando il prodotto tra i valori economici totali per i giorni
effettivamente
ttivamente lavorati (per quanto riguarda il costo) o per
l’avanzamento (nel caso delle due tariffe) relativi al medesimo
preventivo.
60
Inoltre calcola l’efficienza su ogni singolo preventivo, come
rapporto tra avanzamento e giorni totali effettivamente lavorati fino alla
data specificata.
ALTER FUNCTION [dbo].[ConsuntiviConEfficienzaAvaOGiorni]

(
@datafine Datetime,
@gruppo char(30)
)
RETURNS TABLE
AS
RETURN
(
SELECT
idTask, Task, Descrizione, Gruppo, Commessa,
Stato, IdPreventivi, CampoPerGroupBy,
GiorniPeriodo, Preventivo, NumeroTariffe,
Avanzamento, GiorniTotali, AvanzamentoTotale,
DataInizio, Ava_o_giorni_Totale AS Ava_Totale,
CASE WHEN ((Ava_o_giorni_Totale IS NULL) OR

(GiorniTotali=0) OR (GiorniTotali IS NULL))
THEN NULL
ELSE (Ava_o_giorni_Totale / GiorniTotali)
END AS Efficienza,
CASE WHEN (Preventivo=0) THEN NULL

ELSE COALESCE(Preventivo - Ava_o_giorni_Totale,
Preventivo)
END AS A_finire,
Costo_Medio,(Costo_Medio * GiorniTotali) AS
Costo_Totale,
Tariffa_Trasferimento_Media,
(Tariffa_Trasferimento_Media *
Ava_o_giorni_Totale) AS
Ricavo_Totale_Trasferimento,
Tariffa_Mercato_Media,(Tariffa_Mercato_Media *
Ava_o_giorni_Totale) AS Ricavo_Totale_Mercato,
CASE WHEN (GiorniTotali=0) THEN NULL ELSE

(Tariffa_Mercato_Media * Ava_o_giorni_Totale /
GiorniTotali) END AS Tariffa_Media,
GiorniTotaliPersoneLab,
CASE WHEN ((GiorniTotaliPersoneLab IS NULL) OR

(GiorniTotaliPersoneLab=0)) THEN NULL
ELSE ((GiorniTotaliPersoneLab/GiorniTotali)*
Ava_o_giorni_Totale)
END AS AvaTotalePersoneLab
FROM
dbo.ConsuntiviConAvaTot(
@datainizio, @datafine,@gruppo)
)
61
• CostoAziendaleGroupBy
Aggrega per preventivo le persone che hanno svolto attività su
di esso.
Ogni preventivo avrà un proprio costo aziendale totale, tariffa di

trasferimento totale e tariffa di mercato totale, ricavate come somma dei
prodotti tra giorni lavorati sul preventivo di ogni singola persona per i
relativi parametri economici giornalieri.
Si ottengono, in questa maniera, i valori economici totali per

ogni preventivo pesati in base alle differenti persone che hanno lavorato
sullo stesso, inclusi, cioè, nella medesima figura o nell’intero task, a
seconda del tipo di avanzamento del task stesso.
• TaskEstesiPersoneNoGroupDaA
A partire dalle singole attività dei dipendenti collegate ai relativi
preventivi, viene effettuata l’aggregazione, all’interno di ogni distinto
preventivo, per persona che ha svolto l’attività (con la relativa somma
dei giorni lavorati all’interno del preventivo).
Inoltre, per ogni persona, si ottengono i relativi parametri
economici: costo aziendale giornaliero, tariffa di trasferimento
giornaliera e tariffa di mercato anch’essa giornaliera.

• PersoneLabCostoAziendale (Scalar Function)

Ritorna il costo aziendale più recente della persona richiesta in
base alla data specificata.
• PersoneLabTariffaTrasferimento (Scalar Function)

Ritorna la tariffa di trasferimento più recente della persona
richiesta in base alla data specificata.
62
4.4.3.4 Check
heck
• AttivitaPersoneNoLABDaA
AttivitaPer
Ritorna la lista delle singole attività ricavate dai rapportini e
svolte da personale non appartenente al Laboratorio Euris di Trieste tra
l’intervallo di date specificato.
• CheckPersoneNoLabDaA
Ritorna la lista delle singole attività

attività svolte da personale Euris
ma non appartenente al Laboratorio di Trieste, e sottese dai preventivi
appartenenti ai task dei progetti sviluppati nel Laboratorio.
• AttivitaPersoneLABDaA
Ritorna la lista delle singole attività ricavate dai rapportini
rapportin e
svolte solamente da personale appartenente al Laboratorio Euris di
Trieste tra l’intervallo di date specificato.
• CheckCommesseDaANoGroup
Ritorna la lista delle singole attività svolte solamente da
personale appartenente al Laboratorio Euris di Trieste
Trieste che non sono
ancora state collegate ad alcun preventivo e, dunque, ad alcun task
sviluppato dal Laboratorio.
63
ALTER FUNCTION [dbo].[CheckCommesseDaANoGroup]
(
@datafine
afine Datetime
)
RETURNS TABLE
AS
RETURN
(
SELECT
Attivita
Attivita.id, Attivita.Codice_commessa,,
Attivita
Attivita.dsc_commessa,
LTRIM
LTRIM(RTRIM(Attivita.Cognome)) + ' ' +
LTRIM
LTRIM(RTRIM(Attivita.Nome)) AS Persona,
Persona
Attivita
Attivita.Dsc_odl, Attivita.Ore_Durata,
,
Attivita
Attivita.Tariffa,Attivita.Data, Attivita
Attivita.Note,
Attivita
Attivita.FiguraAssegnata
FROM
AttivitaPersoneLABDaA
AttivitaPersoneLABDaA(@datainizio,@datafine
@datafine)
AS Attivita
WHERE
Attivita
Attivita.Id
NOT IN (
SELECT Id
FROM dbo.TaskEstesiAttivitaNoGroupDaA
TaskEstesiAttivitaNoGroupDaA(
@datainizio,@datafine)
WHERE id is not null
)
)
• CheckCommesseDaA
Mostra la lista delle commesse relative ad attività svolte

solamente
mente da personale appartenente al Laboratorio Euris di Trieste che
non sono ancora state collegate ad alcun preventivo e, dunque, ad alcun
task sviluppato dal Laboratorio.
64
• DettaglioCheckCommessa
Ritorna la lista delle singole attività svolte solamente

solamente da
personale appartenente al Laboratorio Euris di Trieste che non sono
ancora state collegate ad alcun preventivo e, dunque, ad alcun task
sviluppato dal Laboratorio e che hanno appartengono alla stessa
commessa (hanno il medesimo codice commessa).
4.4.3.5 Spalmatura
palmatura avanzamenti
• AvanzamentiPrecedentiCommessa
Mostra tutti gli avanzamenti dei task che sono stati spalmati
sulle commesse nei mesi precedenti a quello specificato
65
ALTER FUNCTION [dbo].[AvanzamentiPrecedentiCommessa]
(
@datainizio Datetime
)
RETURNS TABLE
AS
RETURN
(
SELECT
commessa, preventivoGG, avaPrecedente,
IdAvanzamento, IdPreventivi
FROM
(
SELECT
dbo.Commesse.commessa,
dbo.Commesse.preventivoGG,
dbo.Avanzamenti.avaComm1 AS avaPrecedente,
dbo.Avanzamenti.IdAvanzamento,
dbo.Avanzamenti.IdPreventivi
FROM
dbo.Commesse
INNER JOIN dbo.Avanzamenti
ON dbo.Commesse.commessa =
dbo.Avanzamenti.commessa1
WHERE
Anno<YEAR(@datainizio)
OR (Anno=Year(@datainizio)
AND Mese<MONTH(@datainizio))
UNION
SELECT
dbo.Commesse.commessa,
dbo.Commesse.preventivoGG,
dbo.Avanzamenti.avaComm2 AS avaPrecedente,
dbo.Avanzamenti.IdAvanzamento,
dbo.Avanzamenti.IdPreventivi
FROM
dbo.Commesse
INNER JOIN dbo.Avanzamenti
ON dbo.Commesse.commessa =
dbo.Avanzamenti.commessa2
WHERE
Anno<YEAR(@datainizio)
OR (Anno=Year(@datainizio)
AND Mese<MONTH(@datainizio))
) AS AvanzamentiPrecedenti
)
66
• AvanzamentiPrecedentiCommessaConResiduo
amentiPrecedentiCommessaConResiduo
Ritorna la lista di tutte le commesse con i relativi avanzamenti
spalmati su di esse fino al mese precedente a quello specificato e con i
giorni residui da poter erodere.
• AvanzamentiCorrentiCommessa
Ritorna la lista dei Task che hanno subito un avanzamento nel
mese corrente.
Per ognuno di questi task viene indicata la commessa alla quale

sono correntemente legati e il suo residuo e l’avanzamento corrente di
ogni task.
• TaskCommessaDaAvanzare
Ritorna la lista
lista dei Task che hanno subito un avanzamento nel
mese corrente.
Per ognuno di questi task viene indicata la commessa alla quale

sono correntemente legati e il suo residuo, l’avanzamento corrente e la
somma di quelli precedenti dei task.
67
• AvanzamentiPrecedentiCommesseAssegnabili
AvanzamentiPrecedentiCommesseAssegnabili
Ritorna la lista di tutte le commesse, con o senza avanzamenti

spalmati su di esse, i cui giorni di preventivo non sono ancora stati erosi
completamente, cioè che abbiano ancora del residuo.
• AvanzamentiCorrentiTask
Ritorna
torna gli avanzamenti del mese specificato relativi ai
preventivi del task specificato.
68
4.5 Presentation
Le due sezioni precedenti, dedicato alla descrizione

dell’implementazione fisica del Data Layer e della Business Logic con la
relativa codifica in SQL, si sono è occupate di evidenziare il modo nel quale i
dati, presenti nella base dati locale, venissero aggregati e manipolati per la
produzione delle informazioni desiderate in fase di analisi dei requisiti.
Quest’ultima sezione dedicata all’implementazione del progetto di

“Gestione delle commesse software” , si occuperà, a partire dalle trattazioni
precedenti, di descrivere le componenti principali dell’applicazione che
forniscono la presentazione, orientata all’utente, delle informazioni già
elaborate dalla business logic.
La presentazione delle informazioni è suddivisa in due parti, che

verranno trattate diffusamente di seguito, una riguardante lo sviluppo di un
“Pannello di controllo” con WinForm e l’altra focalizzata all’implementazione
di un “Web front-end” realizzato da una WebPart da integrare in MOSS 2007.
4.5.1 Implementazione WinForm

Oltre alla semplice presentazione, questa porzione di implementazione si è
occupata di:
• Fornire la logica per il processo di erosione delle commesse
• Modificare l’interfaccia grafica di alcune componenti Winform

predefinite
• Funzionalità dei filtri di data, stato e gruppo
69
4.5.1.1 Gestione dei dati
La gestione dei dati lato client di presentazione sfrutta diffusamente la
tecnologia ADO.NET 2.0.
Il punto di contatto tra Database e applicativo è rappresentato da una

struttura dati di tipo DataSet, che memorizza localmente diversi set di dati,
filtrati, provenienti da DB e opera da sorgente dati per i controlli tipici di
visualizzazione, come, ad esempio, le DataGridView.
Tramite alcuni TableAdapter che agiscono sul DataSet, è possibile

instaurare una connessione con la base dati esterna e gestire le query di
estrazione dei record dalla base dati stessa.
I TableAdapter si occupano, inoltre, degli inserimenti, delle modifiche e

delle cancellazioni effettuate da interfaccia utente, in modo tale da tenere
sempre sincronizzati i dati reali del Database esterno con la sorgente dati locale
dell’applicazione.
I dati contenuti nel Dataset, chiamato “Lab_Dati_Fatturazione”, sono

suddivisi in tredici diverse DataTable:
Nome DataTable Descrizione

Carica i dati del tipo di avanzamento
direttamente dal Database. Usato nella
TipoAvanzamento DataGridView della gestione di task e
preventivi per l’inserimento e la
modifica dei task.
Controlla i clienti che sono associati a
tutti i task presenti nel sistema.
Gruppi
Utilizzata per popolare la
DropDownList dei Gruppi.
Carica la lista delle commesse
direttamente dal Database. Usato nella
Commesse DataGridView della gestione di task e
preventivi per l’inserimento e la
modifica dei task.
Popola il pannello dei task con tutti i
TaskEstesiVS
valori riguardanti task e preventivi
Popola il pannello Check task
CheckCommesseDaA
mancanti
ConsuntiviDaAConTotali Popola il pannello Avanzamenti
DettaglioCampoPerGroupBy Riempie il dettaglio Avanzamenti
AvanzamentiPrecedenti Utilizzata nel processo di erosione,
70
CommesseAssegnabili fornisce la capienza residua di ogni
commessa fino al mese precedente
rispetto a quello specificato
Popola il dettaglio dei Check task
DettaglioCheckCommessa
mancanti
Popola il pannello Check attività
CheckPersoneNoLabDaA
persone esterne
Utilizzata nel processo di erosione,
ritorna la lista dei task che hanno
TaskCommessaDaAvanzare
subito un avanzamento nel mese
corrente
Popola il pannello degli avanzamenti
ConsuntiviPerTaskGroupBy economici con i task e i relativi valori
economici
Carica il dettaglio degli Avanzamenti
ConsuntiviConAvaTot economici con la lista di preventivi
relativa al task selezionato
Operazioni su DataSet
Sulle DataTable appartenenti al DataSet “Lab_Dati_Fatturazione”, si
possono effettuare le seguenti operazioni:
• Popolamento: vengono inseriti nel DataSet dei dati provenienti dal

Database esterno tramite query su tabelle o su result set di User-
Defined Functions con parametri (ad esempio, data iniziale, data finale,
gruppo).
• Inserimenti, update e cancellazioni: effettuati tramite chiamate alle

Stored Procedure, con parametri, già presentate in fase di
implementazione del Database.
4.5.1.2 Implementazione dei filtri

Nei pannelli dell’applicazione esistono tre tipi di filtri, tutti implementati da
semplici controlli DropDownList:
71
• Data:: le due DropDownList, una riguardante la data di partenza e l’altra
quella finale, sono
sono legate tra loro in modo tale che vengano sempre
visualizzate due date con mese uno successivo all’altro.
Figura 4.4 – Pannello di selezione della data
• Gruppo:: DropDownList che ha come sorgente dati la DataTable

“Gruppi”, permette di selezionare
selezionare uno dei gruppi associati ai task e
filtrare i dati per quel particolare gruppo. Oltre ai nomi dei gruppi è
possibile selezionare “Tutti”, che permette di non effettuare il filtro.
Figura 4.5 – Pannello di filtro gruppo e stato
• Stato: DropDownList
ropDownList che ha come voci selezionabili
o Attivi:
Attivi: visualizza le informazioni dei soli task che hanno lo stato
impostato a true.
o Inattivi:
Inattivi: visualizza le informazioni dei soli task che hanno lo
stato impostato a false.
o Tutti:
Tutti visualizza tutte le informazioni sui task
indipendentemente dallo stato attuale.
72
4.5.1.3 Visualizzazione informazioni
La totalità dei pannelli per la visualizzazione, l’inserimento, la modifica

e la cancellazione controllata di dati è implementata tramite DataGridView.
Questo controllo ADO.NET 2.0 offre la possibilità di poter essere

agganciato ad una sorgente dati specificata di tipo DataTable e,
automaticamente stabilisce una relazione biunivoca tra record visualizzati e
record memorizzati su DataTable.
Questa relazione è necessaria in quanto i DataGridView sono stati

impostati, in alcuni pannelli, come editabili per consentire la modifica dei dati.
Se vengono modificati dei campi nella DataGridView, questa

operazione rimane a livello interfaccia grafica e non influenza i dati presenti
nella DataTable finché non si effettua un aggiornamento esplicito tramite il
metodo Update del TableAdapter relativo alla DataTable.
La formattazione di righe, colonne e headers del DataGridView è

abbastanza limitata se si impostano solamente differenti valori alle proprietà
del controllo.
Nel caso specifico, è stata richiesta la visualizzazione dei task con il

supporto di differenti colorazioni di righe e colonne, per evidenziare
similitudini tra preventivi e gruppi di valori riferibili alle medesime entità. In
particolare:
• Righe: colorazione alternata a gruppi di righe. Ogni gruppo è formato

da task che hanno lo stesso nome. Inoltre viene visualizzato solamente
il nome del primo task, mentre sono cancellati tutti gli altri con il
medesimo nome.
• Colonne: le colonne sono suddivise in gruppi. Ogni gruppo si distingue

dagli altri per l’intervallo temporale al quale si riferiscono i valori delle
colonne che raggruppa (valori totali, valori correnti, valori precedenti,
efficienza).
Per indurre questa particolare formattazione al controllo DataGridView è

stato necessario creare una Classe che eredita da DataGridView e operare su
alcuni metodi un override.
La classe creata è stata chiamata “DataGridViewRowColor”.
73
I due metodi riportati di seguito vengono chiamati automaticamente dal
Framework .NET ogniqualvolta è necessario visualizzare le celle di un
DataGridView.
Il parsing di ogni singola cella viene effettuato sempre con un ordine ben
preciso:
• Partendo dalla prima cella, la prima sulla riga degli headers di colonna,
partendo da sinistra, si controllano tutte le celle sulla stessa riga da
sinistra verso destra.
• Giunti al termine della riga, si riparte dalla prima cella a sinistra della
riga successiva.
Il metodo OnCellFormatting si occupa della formattazione delle celle dopo

aver disegnato la cella e appena prima di renderla visibile sul DataGridView.
Viene effettuato l’override su questo metodo per cancellare i valori

multipli del nome del task o della sua descrizione nel caso in cui due righe
consecutive abbiano lo stesso valore.
Il codice che effettua l’operazione descritta è il seguente:
protected override void OnCellFormatting(

DataGridViewCellFormattingEventArgs args)
{
base.OnCellFormatting(args);
if (args.RowIndex == 0)
return;
string columnName = Columns[args.ColumnIndex].Name;
if
(
columnName.Equals("taskDataGridViewTextBoxColumn1") ||
columnName.Equals("dataGridViewTextBoxColumn1") ||
columnName.Equals("campoPerGroupByDataGridViewTextBoxColumn")
)
{
if (IsRepeatedCellValue(args.RowIndex, args.ColumnIndex))
{
args.Value = string.Empty;
args.FormattingApplied = true;
}
}
}
74
La porzione di codice C# sopra riportata effettua le seguenti operazioni:
• Se la riga della cella corrente è la prima, non fà nulla.
• Se la cella corrente appartiene ad un’altra riga e appartiene ad una tra le

colonne “Nome Task”, “Descrizione” o “CampoPerGroupBy” allora:
o Controlla se la riga precedente ha il nome del task o la

descrizione o il CampoPer GroupBy uguale a quelli della riga
corrente.
o I valori uguali nei campi corrispondenti tra le due righe

confrontate, vengono eliminati sulla riga corrente.
Il metodo OnCellPainting si occupa del disegno di ogni singola cella

sul DataGridView.
Viene effettuato l’override su questo metodo per assegnare un certo

colore ad ogni singola cella in base alla sua posizione di riga (hanno lo stesso
colore le righe vicine con lo stesso nome del task e descrizione) e di colonna
(hanno lo stesso colore le colonne che esprimono valori riferiti a medesimi
intervalli temporali).
Il codice che effettua l’operazione descritta è il seguente:
protected override void OnCellPainting(

DataGridViewCellPaintingEventArgs args)
{
base.OnCellPainting(args);
// Quando inizio il disegno resetto il colore di base

if (args.RowIndex < 0)
{
currentColor = _COLOR_1;
return;
}
// Nuova riga: il colore di riga non è stato ancora modificato

if (args.ColumnIndex < 0)
{
isColorModified = false;
return;
}
75
Se la cella controllata appartiene alla riga degli headers di colonna,
viene settato il colore base.
Se la cella controllata appartiene alla colonna degli headers di riga,

significa che il controllo è giunto ad una nuova riga e dunque non si è ancora
effettuato nessun confronto per un eventuale cambio di colore delle celle.
// Ottengo la colonna ordinata, se non c'è ordino la prima

DataGridViewColumn sortedColumn =
Rows[args.RowIndex].DataGridView.SortedColumn;
if (sortedColumn == null)
{
sortedColumn =
Rows[args.RowIndex].DataGridView.Columns["taskDataGri
dViewTextBoxColumn1"];
}
Controllo la colonna sulla quale si basa l’ordine delle righe.
Se non c’è imposto l’ordinamento sulla colonna del nome del task, per
poter raggruppare le righe.
Infine, in base alla colonna della quale fa parte la cella corrente, effettuo
un confronto per sapere se la riga corrente può essere raggruppata con quella
precedente e in tal caso, alla cella corrente viene assegnato il corretto colore
della colonna, “mescolato” opportunamente con quello della riga sulla quale si
trova la cella.
76
string currentColumnName =
Rows[args.RowIndex].DataGridView.Columns[args.ColumnIndex].
Name.ToString();
if
(
currentColumnName.Equals(
"preventivoDataGridViewTextBoxColumn1") ||
currentColumnName.Equals("Ava_Totale") ||
currentColumnName.Equals("AvaTotalePersoneLab") ||
currentColumnName.Equals("GiorniTotali") ||
currentColumnName.Equals("GiorniTotaliPersoneLab") ||
currentColumnName.Equals("A_finire")
)
{
colorControl(args.RowIndex, sortedColumn.Index, args);
args.CellStyle.BackColor = createColor(deltaR, 0, 0);
}
else if
(
"avanzamentoDataGridViewTextBoxColumn") ||
currentColumnName.Equals("GiorniPeriodo")
)
{
args.CellStyle.BackColor = createColor(0, deltaG, 0);
}
else if (
"avanzamentoTotaleDataGridViewTextBoxColumn"))
{
args.CellStyle.BackColor = createColor(0, 0, deltaB);
}
else if
(
currentColumnName.Equals("Efficienza") ||
"numeroTariffeDataGridViewTextBoxColumn")
)
{
args.CellStyle.BackColor =
createColor(deltaR, deltaG, deltaB);
}
else
{
args.CellStyle.BackColor = currentColor;
}
}
77
Il risultato finale ottenuto è il seguente:
Figura 4.6 – Pannello Avanzamenti
4.5.2 Implementazione Web Part
4.5.2.1 Obiettivo
Progettazione e sviluppo di una WebPart, da utilizzare in un sito MOSS
2007, che consenta la pubblicazione di dati aziendali provenienti da DB.
Le informazioni da visualizzare saranno filtrate o nascoste tramite

permessi associati ai singoli gruppi e ai singoli utenti che accedono al sito
contenente la WebPart.
La gestione di filtri e permessi sarà realizzata da alcuni Editor custom

relativi alla WebPart, editabili dagli amministratori del sito.
78
4.5.2.2 Struttura WebPart
La WebPart, chiamata “AvanzamentiDataGridWP”, permette di

visualizzare una tabella caricata con i dati provenienti da DB aziendale.
La stringa di connessione al DB e la query di selezione dei dati sono

specificati nell’editor “ConnectionParametersEditor”.
Questi dati sono poi filtrati:
• “Verticalmente” dai filtri SQL basati sugli utenti impostati sull’editor

“UsersSqlEditor”
• “Orizzontalmente” dai permessi di visualizzazione sulle colonne

impostati impostati sull’editor “GroupsColumnsEditor”
Alla Web Part potranno accedere diversi tipi di utenti, tutti inseriti
all’interno di gruppi gestiti dal sito Sharepoint in oggetto.
Utenti e gruppi possono essere impostati tramite integrazione con un

sistema di Active Directory già esistente internamente all’azienda, oppure
creandoli direttamente all’interno del sito Sharepoint sfruttando
l’autenticazione base di Windows.
Ogni utente del sito Sharepoint, appartenente ad uno o più gruppi, una
volta effettuata l’autenticazione, visualizzerà la WebPart in oggetto.
Nel caso reale, cioè l’utilizzo dedicato alla pubblicazione di dati su

progetti o sul personale di un’azienda informatica, gli utenti saranno
tipicamente suddivisi in 5 gruppi:
• Amministratori: hanno la possibilità di effettuare l’editing dei

permessi di visualizzazione sulla WebPart e, dunque, possono gestire
personalmente i propri permessi. Si può quindi considerare che essi
possano accedere a qualunque dato.
• Commerciali: gestiscono la parte finanziaria dell’attività dell’azienda e

sono tipicamente interessati ai costi relativi ai dipendenti e tutto ciò che
riguarda il rapporto a livello economico con il cliente.
79
• Responsabili dell’attività tecnica: hanno interesse a tenere sotto
controllo l’attività propria di sviluppo di applicativi per il cliente. I
parametri ai quali sono interessati sono, tipicamente, lo stato di
avanzamento di tutti i progetti dei quali sono responsabili, la
distribuzione delle ore lavorate da parte dei dipendenti nei diversi
progetti e l’efficienza del team di sviluppo sul singolo progetto o su
tutti i progetti attualmente in fase di sviluppo. La misura dell’efficienza
può essere calcolata, ad esempio, come rapporto tra avanzamento, fino
alla data attuale, e giorni effettivamente lavorati sul task.
• Personale: membri del Laboratorio o dipendenti della società

informatica che tipicamente avranno accesso alle proprie informazioni
personali riguardo alla retribuzione e alle ore lavorate su ogni progetto
e lo stato di avanzamento dei progetti in fase di sviluppo.
• Clienti: visualizzano la sola WebPart, accedendo dall’esterno rispetto

all’azienda informatica, la quale mostrerà dati, sia tecnici (stato di
avanzamento del progetto) che economici (costo delle commesse).
La Web Part sviluppata non è vincolata alla presenza di un determinato

numero o tipo di gruppi o utenti, infatti è possibile personalizzare i permessi di
visualizzazione per un qualsiasi numero o tipo di gruppi o utenti ed, inoltre, è
possibile utilizzare una qualsivoglia sorgente dati Database e, da essa,
pubblicare un set di dati da una struttura tabellare.
Tutto ciò è possibile in quanto si è cercato il più possibile di rendere lo

sviluppo della Web Part, e il successivo utilizzo, indipendente dai dati che
sarebbero stati visualizzati.
Solo gli utenti appartenenti al gruppo degli amministratori, specificato

nelle impostazioni del singolo sito Sharepoint, potranno accedere all’Editor
delle WebPart, mentre tutti gli altri utenti avranno solamente la possibilità di
visualizzare la WebPart filtrata con i parametri impostati dagli amministratori.
80
4.5.2.3 Struttura EditorPart
• GroupsColumnsEditor
Consente di selezionare, per ogni gruppo appartenente al sito

corrente, le colonne che la tabella (presente nella WebPart) dovrà
visualizzare in base ai permessi di visibilità assegnati al gruppo di
appartenenza dell’utente corrente.
Le colonne selezionabili sono visualizzate dinamicamente in

base alla query sql di selezione impostata nell’editor
“ConnectionParametersEditor”.
E’ possibile selezionare le colonne da visualizzare in modo

indipendente tra un gruppo e l’altro.
Nel caso in cui un utente appartenga a più di un gruppo presente

nella lista, esso avrà i permessi di visualizzazione ricavati dall’unione
tra i permessi assegnati ad ogni gruppo di cui fa parte l’utente.
Ogni gruppo di utenti sarà selezionabile da una lista che conterrà

tutti i gruppi di utenti che possono accedere al sito Sharepoint nel quale
è stata inserita la Web Part.
Figura 4.7 – EditorPart Groups Columns Visibility
81
• UsersSqlEditor
Permette di inserire, per ogni utente appartenente al sito

corrente, un filtro SQL per selezionare i record da visualizzare sulla
tabella in base all’utente corrente.
Ogni utente potrà avere una clausola WHERE diversa e

indipendente dagli altri utenti.
Ogni utente sarà selezionabile da una lista che conterrà tutti gli
utenti che possono accedere al sito Sharepoint nel quale è stata inserita
la Web Part.
Figura 4.7 – EditorPart Users SQL Filter
• ConnectionParametersEditor
Consente di specificare la stringa di connessione al Database e

la query SQL per il caricamento dei dati nella tabella della WebPart.
Quando viene modificata la stringa di connessione al Database o

la query SQL o entrambe, procedendo alla validazione e la conseguente
applicazione della modifica, viene ricaricato il “GroupsColumnsEditor”
con i nomi identificativi delle colonne del set di dati corrispondente ai
nuovi parametri inseriti.
82
Figura 4.8 – EditorPart Parametri di Connessione DB
4.5.2.4 Implementazione WebPart
I controlli lato server utilizzati nell’implementazione della Web Part e

delle relative Editor Part sono quelli di ASP.NET 2.0 (Button, TextBox,
DropDownList,…), ma sono utilizzati nella modalità di programmazione ad
oggetti C# classica senza sfruttare, cioè, i tag tipici della programmazione
ASP.NET 2.0.
Questa scelta è dovuta principalmente a due ragioni:
• Macchinosità del deploy manuale delle WebParts su MOSS 2007, a

causa dell’assenza di un tool automatico
• Necessario copiare il codice sorgente degli User Controls (creati con

ASP.NET) nelle directory virtuali delle web application di Sharepoint,
non potendo utilizzare gli Assembly.
83
Figura 4.9 – WebPart AvanzamentiDataGridWP
La Web Part è una classe che eredita da

System.Web.UI.WebControls.WebParts.WebPart.
public class AvanzamentiDataGridWP:

System.Web.UI.WebControls.WebParts.WebPart
Per rendere persistenti le impostazioni degli editor, è stato sfruttato il

metodo di serializzazione di default di MOSS 2007, cioè salvando i dati
(preventivamente codificati) su stringhe variabili membro della WebPart con i
seguenti attributi:
• WebBrowsable(false) → controllo non visibile sull’editor.
• Personalizable(PersonalizationScope.Shared) → Valori impostati

condivisi da tutti gli utenti del sito che utilizzano la WebPart.
Il seguente è un esempio di definizione di una variabile membro della

WebPart come stringa per la memorizzazione persistente della query SQL.
84
[WebBrowsable(false),
Personalizable(PersonalizationScope.Shared)]
public String ConnectionString
{
get
{
return this._CONNECTION_STRING;
}
set
{
this._CONNECTION_STRING = value;
}
}
Di default, impostando il valore “true” all’attributo “WebBrowsable”,

sulla parte standard dell’editor della Web Part verrà visualizzato il controllo
lato server associato al tipo primitivo della variabile membro in questione.
Le associazioni provate sono:
string → TextBox
bool → CheckBox
In base a quanto detto precedentemente, le stringhe contenenti le

impostazioni codificate degli editor, non saranno associate ad alcun controllo
server e saranno quindi “nascoste”, ma memorizzate in modo persistente sulla
WebPart.
Queste stringhe sono le seguenti:
• ConnectionString: stringa di connessione al DB. Ha il seguente

formato:
Data Source=MOSSWLAB2003\SQLEXPRESS;Initial Catalog=WebPartsTest;Integrated

Security=True
85
• SqlQueryString: query SQL per il caricamento dei dati da DB. Ha il
seguente formato:
"select * from Task"
• GroupsColumnsString: stringa codificata contenente i permessi di

visibilità sulle colonne del datagrid, suddivisi per gruppo di
appartenenza dell’utente. Ha il seguente formato:
nome_gruppo1,nome_colonna1:permesso!nome_colonna2:permesso!...!;nome_gruppo2,
nome_colonna1:permesso!....!;
Con:
o Nome_Gruppo: nome identificativo del gruppo
o Nome_Colonna: nome identificativo della colonna da

visualizzare
o Permesso: valore booleano (True/False) che rappresenta il

permesso di visualizzazione della colonna specificata
• UsersSqlString: stringa codificata contenente i filtri SQL (tipicamente

una clausola WHERE) associati ad ogni singolo utente. Ogni utente può
avere un unico filtro associato.
Ha il seguente formato:
nome_utente1,filtro_sql;nome_utente2,filtro_sql;
86
NOTA SUL FORMATO DELLE STRINGHE SQL
E’ stata implementata una funzionalità di riconoscimento di tag ad hoc,
inseribili all’interno della query SQL di connessione e dei filtri SQL relativi
agli utenti. Questi tag, in sede di caricamento dati da DB, vengono sostituiti dai
valori che rappresentano.
I tag hanno il seguente formato:
<nome_tag>
e sono i seguenti:
• <user> → utente connesso
• <datetime> → data e ora attuale
• <site> → nome del sito corrente
PROBLEMI RISCONTRATI
private string GetCurrentUser()

{
SPWeb currentWebSite =
SPControl.GetContextWeb(Context);
SPUser currentWebSiteUser = currentWebSite.CurrentUser;
return currentWebSiteUser.LoginName;
}
Per ottenere l’utente connesso attualmente è necessario utilizzare la

proprietà “LoginName” perché usando la proprietà “Name”, viene preso in
considerazione l’utente “NT AUTHORITY\LOCAL SERVICE” che gestisce
la cache.
87
4.5.2.5 Implementazione EditorPart
Figura 4.10 – EditorPart completa
Il metodo CreateChildControls dell’istanza della classe

GroupsColumnsEditor, ha il compito di creare i controlli sull’EditorPart.
Questo processo viene effettuato ad ogni PostBack della Request HTTP.
88
Ogniqualvolta il numero di CheckBox aggiunte alla collezione dei
Controlli della EditorPart è maggiore di quelle create precedentemente, si
presenta un errore non gestibile.
E’ dunque necessario garantire che, ad ogni PostBack, il numero di

CheckBox inserite nella EditorPart siano in numero minore o uguale al
caricamento precedente.
Dato che il numero di colonne presenti nel set di record ritornati dalla
query SQL definita, può essere sempre variabile, per ovviare al problema si è
pensato di inserire ogni volta un numero fisso di CheckBox
(maxColumnsNumber definito come costante intera): le CheckBox che
rappresentano le colonne vengono visualizzate, mentre le altre vengono rese
non visibili.
In fase di rendering, poi, tutte le CheckBox non visibili non vengono

renderizzate.
Il codice che fa ciò è il seguente:
foreach (string colName in columnsNameList)

{
CheckBox newCheckBox = new CheckBox();
newCheckBox.ID = colName;
newCheckBox.Text = "Colonna " + colName + "";
Controls.Add(newCheckBox);
}
int columnsToAdd = maxColumnsNumber - columnsNameList.Count;
for (int i = 0; i < columnsToAdd;i++ )

{
CheckBox newCheckBox = new CheckBox();
newCheckBox.Visible = false;
Controls.Add(newCheckBox);
}
89
VARIABILI DI SESSIONE
Le variabili di sessione sono ottenute tramite la proprietà “WebPartManager”
della WebPart.
this.WebPartManager.Page.Session.Remove(
"previousUserSelection")
• previousUserSelection: stringa contenente il nome dell’utente

selezionato precedentemente, rispetto alla nuova selezione sulla
DropDownList
• editorUsersFilter: Dictionary contenente coppie nome_utente–

filtro_SQL.
• previousGroupSelection: stringa contenente il nome del gruppo

selezionato precedentemente, rispetto alla nuova selezione sulla
DropDownList
• editorGroupsColumns: Dictionary contenente coppie nome_gruppo-

lista_colonne_con_permessi
• connectionString: stringa di connessione al DB
• sqlQueryString: query SQL per il caricamento dei dati da DB
• columnsNameList: lista delle colonne dei record ritornati dalla query

SQL
90
4.5.2.6 Life Cycle di WebPart e Editor Part
Il Framework di Sharepoint gestisce il caricamento dei dati, la loro
memorizzazione persistente e la visualizzazione dei controlli sulla pagina del
sito dove è presente la Web Part, effettuando delle chiamate in un certo ordine
ed a alcuni particolari metodi delle classi astratte WebPart e EditorPart.
Il Framework, oltre a questi metodi, né chiama altri, non gestibili da

codice custom i quali gestiscono, ad esempio, la serializzazione e la
memorizzazione dei dati su DB e altre funzionalità.
• Metodi overrided della WebPart
protected override void OnEditModeChanged(EventArgs e)
Chiamata in ingresso e in uscita alla/dalla modalità editing della

WebPart
public override EditorPartCollection CreateEditorParts()
Istanzia le EditorPart relative alla WebPart e le inserisce in una

collezione
• Metodi overrided delle EditorPart
public override void SyncChanges()
Aggiorna l'Editor Part con i valori forniti dalla Web Part associata
(sincronizzazione)
91
public override bool ApplyChanges()
Salva sulla Web Part i dati inseriti nella Editor Part associata
• Metodi overrided comuni a WebPart e EditorPart
protected override void CreateChildControls()
Crea i controlli della User Interface
protected override void Render(HtmlTextWriter writer)
Formatta l’aspetto della WebPart o dell’EditorPart
Ordine delle chiamate ai metodi da parte del Framework di

Sharepoint
Legenda
AvanzamentiDataGridWP
GroupsColumnsEditor
UsersSqlEditor
ConnectionParametersEditor
92
• Caricamento WebPart in stato Browsable
CreateChildControls
Render
• Apertura WebPart in modifica (Modify Shared WebPart)
OnEditModeChanged
CreateChildControls
CreateEditorParts
CreateChildControls
SyncChanges
Render
CreateChildControls
Render
SyncChanges
Render
CreateChildControls
Render
SyncChanges
93
• Evento di un controllo
CreateEditorParts
CreateChildControls
Render
CreateChildControls
Render
CreateChildControls
Render
CreateChildControls
Render
Metodo chiamato
dall’Handler degli eventi
• Pressione tasto “Apply”
CreateEditorParts
SyncChanges
CreateChildControls
SyncChanges
CreateChildControls
SyncChanges
CreateChildControls
Render
CreateChildControls
Render
ApplyChanges
Render
ApplyChanges
Render
ApplyChanges
94
• Pressione tasto “OK”
CreateEditorParts
ApplyChanges
CreateChildControls
SyncChanges
CreateChildControls
SyncChanges
CreateChildControls
SyncChanges
CreateChildControls
OnEditModeChanged
ApplyChanges
Render
ApplyChanges
• Pressione tasto “Cancel”
CreateEditorParts
CreateChildControls
CreateChildControls
OnEditModeChanged
CreateChildControls
Render
CreateChildControls
95
5 CONCLUSIONI
L’applicazione sviluppata e descritta dettagliatamente in questa tesi, si
divide in due parti:
• Pannello di controllo: per la gestione completa del monitoraggio,

consuntivazione e controllo della situazione produttiva mensile
dell’attività tecnica del Laboratorio Euris
• Web front-end: integrato sul sito Sharepoint ufficiale del Laboratorio,

utilizzato per la pubblicazione e profilazione, a diverse tipologie di
utente, dei contenuti generati dal pannello di controllo
Gli obiettivi pianificati in fase di Analisi sono stati completamente

raggiunti ed, inoltre, l’applicazione è stata testata e risulta perfettamente
funzionante in relazione alle specifiche iniziali.
Le fasi ordinate per il corretto svolgimento del lavoro, impostate in

precedenza, sono state completamente osservate, con la sola esclusione del
deploy della WebPart sul sito ufficiale del Laboratorio operante su dati di
produzione.
Gli obiettivi tattici seguenti evidenziano il percorso di sviluppo seguito:
Formalizzazione dei casi d’uso con il supporto degli utenti finali

Definizione degli attori operanti sul sistema
Analisi delle entità da considerare e dei reciproci legami
Definizione dell’architettura e dei rapporti con sistemi esterni
Generazione degli schemi concettuali e logici della base dati
Progettazione delle funzionalità dei pannelli di controllo
Implementazione delle funzionalità progettate e dell’interfaccia
grafica
Test dell’applicativo di gestione della situazione produttiva con dati
di prova
Deploy del sistema con dati di produzione
Definizione di attori e relativi permessi di accesso ai dati pubblicati
Implementazione delle funzionalità dell’applicazione web
Test della WebPart con dati di prova
Messa in produzione del Web Front-end sul sito del Laboratorio
Il lavoro, descritto nel dettaglio in questa tesi, si è rivelato

didatticamente interessante e stimolante in quanto, mentre ero intento a
svilupparlo, ho avuto la possibilità di toccare con mano quali fossero alcune
delle problematiche focali nella gestione tecnica e commerciale dell’attività di
un azienda informatica.
96
Durante lo sviluppo del progetto ho dovuto confrontarmi inizialmente
con problematiche di carattere prettamente tecnico (analisi e progettazione di
Database relazionali e acquisizione di esperienza nella codifica C# e SQL) per
passare successivamente ad una fase di puro apprendimento su una tecnologia
per me del tutto nuova come MOSS 2007, utile allo sviluppo e l’integrazione di
WebPart.
L’attività svolta è stata estremamente produttiva, sia dal punto di vista

dell’esperienza che da quello dell’apprendimento, anche perché ho avuto la
possibilità di lavorare all’interno di un gruppo di persone competenti e
disponibili.
97

Signoretti-Tesi Specialistica

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Signoretti-Tesi Specialistica

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSITÀ DEGLI STUDI DI TRIESTE

CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA

Anno Accademico 2007-2008

Tali progetti pongono diverse problematiche:

• Sono presenti in numero elevato e affrontati contemporaneamente

• Sono sviluppati su diverse tecnologie

• Sono affrontati con team differenti che si possono “intersecare”

• Sono gestiti in modo “Fixed Budget”, cioè fatturando al cliente la

L’applicativo è stato, inoltre, progettato per integrarsi con diversi sistemi

L’utilizzo dell’applicazione è rivolto ai diversi capi progetto presenti in

1.1 Motivazioni del lavoro

Per i motivi appena descritti, sarebbe inutile affidarsi ad una soluzione

In conseguenza a quanto è stato detto, si è giustificata l’utilità nello

1.2 Obiettivi tattici

Formalizzazione dei casi d’uso con il supporto degli utenti finali

Inoltre, i punti essenziali su cui è necessario soffermarsi durante lo

• Consuntivazione delle attività in maniera flessibile, in quanto ogni

• Trasformazione del progresso tecnico di ogni progetto in grandezza

• Produzione di dati di avanzamento coerenti con le esigenze del

• Pubblicare di dati della produzione al resto dell’azienda e al cliente in

1.3 Vincoli di Progetto

• Utilizzo di tecnologie Microsoft in uso presso l’azienda, in particolare il

• Lo sviluppo dell’applicazione è rivolto all’utilizzo interno del

• E’ previsto, inoltre, che l’analisi del sistema sia semplificata rispetto

• Capitolo 3 – Casi d’uso: definizione dettagliata delle funzionalità

• Capitolo 4 – Implementazione: sviluppo del sistema, comprensivo di

• Capitolo 5 – Conclusioni: valutazione conclusiva del lavoro effettuato,

Dall’esposizione delle problematiche reali e dei concetti specifici sui quali

L’analisi funzionale è riportata di seguito.

Gli attori coinvolti sono i seguenti:

2.1.2 Euris Solutions S.p.A.

2.1.3 Azienda cliente

Le entità rappresentano i concetti astratti sui quali si basa

2.2.1 Task e preventivi

La definizione di task, preventivi e relativi attributi è riportata di seguito.

Ogni Task può essere sviluppato da un diverso numero di persone

Le giornate di preventivo sono importanti sia a fini economici sia a fini

Nel limite del possibile l’azienda dichiarerà come preventivo un

I singoli preventivi non sono forzatamente legati ad un unico Task, ma

In base al tipo di avanzamento fissato, ad un Task possono essere

TIPO AVANZAMENTO DESCRIZIONE

La distinzione tra singole persone, gruppi o task interi viene decisa in

La differenza tra preventivo e giorni effettivamente lavorati dà il

2.2.1.3 Attributi di task e preventivo

• Nome del Task: è un codice che identifica univocamente il task.

• Descrizione: descrive, in modo estremamente sintetico, la tipologia

• Commessa: codice della commessa dalla quale il task sta attualmente

• Gruppo: denominazione dell’azienda cliente con la quale si è stretto un

• Tipo di Avanzamento: rappresenta la modalità con la quale vengono

• Stato: ha un valore binario, definisce se il progetto relativo al task è

• Preventivo: numero delle giornate lavorative o, per essere più precisi,

Tipo di Avanzamento Figura

2.2.2 Gestione degli Avanzamenti

La definizione di avanzamenti e relativi attributi è riportata di seguito.

L’avanzamento è legato al singolo preventivo e non direttamente al

Le ore di avanzamento vengono decise generalmente dal capo progetto

2.2.2.2 Attributi di avanzamento

• Nome del Task: codice che identifica univocamente il task.

• Descrizione: descrizione auto esplicativa del task.

• Preventivo: giornate-uomo necessarie al fine di terminare il progetto.

N.B. Nome del task, descrizione e preventivo hanno lo stesso

• Avanzamento precedente: rappresenta la somma di tutti gli avanzamenti

• Avanzamento precedente delle persone del laboratorio: ha il medesimo

• Avanzamento corrente: avanzamento stimato, relativo ad un certo