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: Alessandro SIGNORETTI

RELATORE: Chiar.mo Prof. Marco PARENZAN CORRELATORE: Ing. Mauro INZERILLO

Anno Accademico 2007-2008

Sommario 1

2

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

ANALISI FUNZIONALE ............................................................................................. 8 2.1

2.1.1

Laboratorio ............................................................................................ 8

2.1.2

Euris Solutions S.p.A. ............................................................................. 9

2.1.3

Azienda cliente ....................................................................................... 9

2.2

4

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 3

Attori .............................................................................................................. 8

Schema concettuale delle entità ................................................................. 30

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

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

4.4.1

Viste ..................................................................................................... 49

4.4.2

Stored Procedure ................................................................................. 50

4.4.3

User-Defined Functions ....................................................................... 54

4.5

5

Business Logic .............................................................................................. 48

Presentation................................................................................................. 69

4.5.1

Implementazione WinForm ................................................................. 69

4.5.2

Implementazione Web Part ................................................................. 78

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

Commessa

Commessa figura

DESCRIZIONE Esiste un solo preventivo relativo ad una commessa (formata da uno o più Task di uno stesso cliente). Vengono 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 di lavoro dei dipendenti registrate con lo stesso codice commessa e appartenenti alla medesima figura.

11

Commessa Persona

Task

Task figura

Task persona

Esiste un preventivo per ogni singola persona che partecipa allo sviluppo dei Task afferenti alla commessa. 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 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 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 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 Commessa, Task Commessa figura, Task figura Commessa persona, Task persona

2.2.2

Figura Nessuna Capo progetto, analista programmatore, programmatore senior, programmatore junior, CP, AP, ecc… Nome del dipendente

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. 

      



Con n = numero dei preventivi afferenti al task. •

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. 

     



Con n = numero dei preventivi afferenti al task. •

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

→

Task

→

Commessa 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 → Task

→

Commessa 1 Task 1

Task 2

Commessa 2 Task 3

Task Task Task 5 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. Viene calcolato in base ad uno dei seguenti casi: 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. Viene calcolato in base ad uno dei seguenti casi: 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 Descrizione Task

Codice Gruppo Commessa

Tipo di avanzamento

Stato

Preventivo Figura

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

Nome Descr Task

Preventivo

Ava totale

Ava totale persone Lab

Giorni totali

Giorni totali persone Lab

A finire

Ava

Giorni

Ava prec

Efficienza

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 ODL

Descrizione ODL

Ore

Task

Tariffa

Data

Persona Note Commessa Figura

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.



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.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 commessa

Descrizione commessa

Descrizione ODL

Persona

Figura Ore Tariffa Data Note

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.

o Ordinamento: basato sull’ordine alfabetico, crescente o 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. L’aspetto della sezione seguirà l’impostazione del seguente schema:

Codice commessa

Descrizione commessa

Descrizione ODL

Persona

Figura Ore Tariffa Data Note

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 selezionato, non al giorno in particolare.

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.

L’aspetto della sezione seguirà l’impostazione del seguente schema:

37

Sezione Avanzamenti

Commessa

Costo medio

Costo totale

Tariffa di trasf. media

Ricavo totale di trasf.

Tariffa di mercato media

Ricavo totale Tariffa di 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 selezionato, non al giorno in particolare. 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, 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. L’aspetto della sezione seguirà l’impostazione del seguente schema:

Commessa

Residuo Commessa

Task

Descrizione

Avanzamento Corrente

Avanzamento Residuo Scaricato Commessa

Avanzamento seconda 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:

Task

Residuo

Commesse con capienza

Residuo 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 Size

Allows null

Chiave

false

PK

Attributi

Tipo

IdTask

int

Task

nchar

100

false

Descrizione

nchar

100

true

Commessa

nchar

20

true

TipoAvanzamento

int

false

Stato

bit

false

DataInizioTask

datetime

true

Gruppo

nchar

Descrizione Identificativo univoco task Denominazione del Task Descrizione estesa del Task Commessa dalla quale il Task sta erodendo le giornate

FK su Tipo Avanzame nto

Tipo di avanzamento determinato per il Task Stato di attività del Task Data di inizio attività sul Task Denominazione dell'azienda cliente

30

true

Allows null

Chiave

Descrizione

false

PK

Identificativo univoco preventivo

Preventivi Attributi

Tipo

IdPreventivi

int

Figura

nchar

Size

70

true

Breve descrizione del gruppo, della figura o della singola persona a cui si riferisce il preventivo Numero di giornate di preventivo sulla commessa, il task, la figura o la persona in base al tipo di avanzamento previsto

Preventivo

float

true

IdTask

int

false

FK su Task

Task al quale afferisce il preventivo

44

Avanzamenti Allows null

Chiave

int

false

PK

Mese

int

false

Identificativo univoco avanzamento Mese avanzamento

Anno

int

false

Anno avanzamento

Avanzamento

float

true

Numero di giornate di avanzamento mensile

IdPreventivi

int

false

Attributi

Tipo

IdAvanzamento

commessa1

nchar

avaComm1

float

commessa2

nchar

avaComm2

float

Size

20

FK su Preventivi Codice della 1° commessa sulla quale viene spalmato l'avanzamento mensile del preventivo Numero di giornate di avanzamento mensile spalmate sulla 1° commessa Codice dell'eventuale 2° commessa sulla quale viene spalmato l'avanzamento mensile del preventivo Numero di giornate di avanzamento mensile spalmate sull'eventuale 2° commessa

true

true

20

Descrizione

true

true

TipoAvanzamento Attributi

Tipo Size

Allows null

Chiave

false

PK

ID_tipo

int

tipo

nchar

40

true

descrizione

nchar

100

true

Descrizione Identificativo univoco tipo di avanzamento Denominazione del tipo di avanzamento Descrizione estesa del tipo 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.

Size

Allows null

Chiave

false

PK

Attributi

Tipo

id_persona

int

cognome

nchar

40

false

nome

nchar

30

false

dataInizioValidita

datetime

false

costoAziendale

money

false

tariffaTrasferimento

money

true

personaLaboratorioTS

bit

false

Descrizione Identificativo univoco persona Cognome della persona Nome della persona Data a decorrere della quale sono in vigore il Costo Aziendale e la Tariffa di Trasferimento specificati Costo giornaliero della persona sostenuto dal Laboratorio per attività del Laboratorio Costo giornaliero della persona sostenuto dalla Euris, per attività interne o esterne al Laboratorio Determina se una persona è membro o meno del Laboratorio di Trieste

Commesse Attributi

Tipo Size

commessa

nchar

preventivoGG

real

20

Allows Chiave null false false

PK

Descrizione Codice identificativo univoco alfanumerico della commessa Numero totale delle giornate 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.

Size

Allows Chiave null

Attributi

Tipo

id

int

Cognome

nvarchar

50

false

Identificativo univoco dipendente Cognome del dipendente

Nome

nvarchar

50

false

Nome del dipendente

Ore_Durata

real

false

Data

datetime

false

Dsc_odl

nvarchar

50

true

Note

nvarchar

200

true

Codice_commessa

nvarchar

20

false

dsc_commessa

nvarchar

50

true

codice_odl

nvarchar

20

false

Tariffa

money

FiguraAssegnata

nvarchar

80

true

TipoOrdineLavoro

nvarchar

8

true

false

true

PK

Descrizione

Ore effettivamente lavorate sull'attività specificata Data di svolgimento dell'attività Descrizione estesa dell'Ordine di Lavoro Note eventuali Codice univoco della commessa Descrizione della commessa Codice univoco dell'Ordine di Lavoro Tariffa di mercato del dipendente, è il costo sostenuto dal cliente per ogni sua giornata di lavoro Figura assegnata al dipendente Gruppo interno all'Euris al 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 Function possono essere suddivise in gruppi che Le User-Defined 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. Le attività considerate sono quelle con data appartenente all’intervallo specificato. 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.TipoAvanzamento, dbo.TaskEstesiVS.Task, 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.TaskEstesiVS.Task, dbo.DatiPresenzeDaA.Tariffa, dbo.DatiPresenzeDaA.Data, dbo.DatiPresenzeDaA.Cognome, dbo.DatiPresenzeDaA.Nome, dbo.DatiPresenzeDaA.Note, dbo.DatiPresenzeDaA.Codice_commessa, dbo.DatiPresenzeDaA.FiguraAssegnata, dbo.DatiPresenzeDaA.id, dbo.DatiPresenzeDaA.codice_odl FROM dbo.TaskEstesiVS LEFT OUTER JOIN dbo.DatiPresenzeDaA(@datainizio, @datafine) ON dbo.JoinTaskAttivita( dbo.TaskEstesiVS.TipoAvanzamento, dbo.TaskEstesiVS.Task, dbo.DatiPresenzeDaA.Dsc_odl, dbo.TaskEstesiVS.Figura, dbo.DatiPresenzeDaA.FiguraAssegnata, dbo.DatiPresenzeDaA.Codice_commessa, 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] ( @datainizio Datetime, @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. Le attività considerate sono quelle con data appartenente all’intervallo specificato.

•

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. Il codice SQL della funzione è il seguente: 63

ALTER FUNCTION [dbo].[CheckCommesseDaANoGroup] ( @datainizio Datetime, @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 Il codice SQL della funzione è il seguente:

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
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

TipoAvanzamento

Gruppi

Commesse

TaskEstesiVS CheckCommesseDaA ConsuntiviDaAConTotali DettaglioCampoPerGroupBy AvanzamentiPrecedenti

Descrizione Carica i dati del tipo di avanzamento direttamente dal Database. Usato nella 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. Utilizzata per popolare la DropDownList dei Gruppi. Carica la lista delle commesse direttamente dal Database. Usato nella DataGridView della gestione di task e preventivi per l’inserimento e la modifica dei task. Popola il pannello dei task con tutti i valori riguardanti task e preventivi Popola il pannello Check task mancanti Popola il pannello Avanzamenti Riempie il dettaglio Avanzamenti Utilizzata nel processo di erosione,

70

CommesseAssegnabili

DettaglioCheckCommessa CheckPersoneNoLabDaA

TaskCommessaDaAvanzare

ConsuntiviPerTaskGroupBy

ConsuntiviConAvaTot

fornisce la capienza residua di ogni commessa fino al mese precedente rispetto a quello specificato Popola il dettaglio dei Check task mancanti Popola il pannello Check attività persone esterne Utilizzata nel processo di erosione, ritorna la lista dei task che hanno subito un avanzamento nel mese corrente Popola il pannello degli avanzamenti economici con i task e i relativi valori economici Carica il dettaglio degli Avanzamenti 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 UserDefined 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 ( currentColumnName.Equals( "avanzamentoDataGridViewTextBoxColumn") || currentColumnName.Equals("GiorniPeriodo") ) { colorControl(args.RowIndex, sortedColumn.Index, args); args.CellStyle.BackColor = createColor(0, deltaG, 0); } else if ( currentColumnName.Equals( "avanzamentoTotaleDataGridViewTextBoxColumn")) { colorControl(args.RowIndex, sortedColumn.Index, args); args.CellStyle.BackColor = createColor(0, 0, deltaB); } else if ( currentColumnName.Equals("Efficienza") || currentColumnName.Equals( "numeroTariffeDataGridViewTextBoxColumn") ) { colorControl(args.RowIndex, sortedColumn.Index, args); args.CellStyle.BackColor = createColor(deltaR, deltaG, deltaB); } else { colorControl(args.RowIndex, sortedColumn.Index, args); 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 • → 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_gruppolista_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