Insieme al gruppo WebUnistage abbiamo studiato la possibilità di realizzare una pagina del Corso di Laurea di Informatica che offra agli studenti servizi orientati all’inserimento nel mondo del lavoro.
Questo è stato deciso perché WebUnistage, ispirandosi a un servizio offerto dall’Università di Milano, si proponeva di realizzare una bacheca elettronica consultabile pubblicamente ove confluissero offerte di lavoro, borse di studio e stage, mentre noi avevamo pensato a un meccanismo per cui le aziende potessero ricercarsi, tra gli studenti che cercano lavoro, il personale con le competenze volute attingendo a una base di dati in cui ogni studente aveva precedentemente inserito le proprie conoscenze con un atto di autocertificazione.
In sede di dibattito della Short Proposal il gruppo gestionale, intravedendo nei due progetti un’area tematica comune, ha deciso di trattare insieme i due progetti. Questo ha permesso ai due gruppi interessati di poter confrontare i relativi progetti e di scorgere dei punti di convergenza nella struttura ma soprattutto nelle finalità. Di qui è nata l’idea di una pagina che centralizzi l’accesso a entrambi i servizi e pensata per raccogliere un domani tutti quei servizi che potrebbero nascere all’interno del nostro Corso di Laurea con la finalità di avvicinare la nostra realtà accademica al mondo del lavoro.
Tale pagina deve permettere di visionare una licenza d’uso e un manuale del sito in linea: entrambi questi documenti devono iniziare con una sezione comune e contenere, se necessario, sezioni separate per ciascuno dei servizi offerti. Deve inoltre permettere di accedere ai diversi servizi.
I servizi offerti da WebUnistage e da CAP sono integrati per cui, nel seguito di questo paragrafo, li affronterò in maniera organica.
Ci sono sostanzialmente quattro classi di utenza:
Nel seguito della Long Proposal definiremo chiaramente quali parti del sito sono comuni, quali sono sviluppati da WebUnistage e quali da noi, nello specifico:
In questo modo rispetteremo la scaletta data dal gruppo gestionale adattandola alla nostra realtà progettuale.
2 – descrizione tecnica del progetto
2.0 - Interfaccia del programma e funzionalità offerte
Il servizio si propone di fornire un'efficace ed intuitiva forma di comunicazione azienda-studente.
Al momento del collegamento viene visualizzata la pagina principale che ha il compito di presentare il servizio e di permettere l’accesso alle sezioni relative a ciascuna classe di utenza: studenti, offerenti, amministratore e pubblico.
Le cose presenti sulla pagina disponibili al pubblico, ossia a tutti (comprese tutte le altre classi d’utenza e il navigatore occasionale) sono:
L’amministratore di sistema accede dalla pagina principale a una pagina che gli consentirà di compiere certe operazioni, come cancellare un annuncio in bacheca o tutti i riferimenti a un offerente. Questa parte dell’interfaccia è gestita dal gruppo WebUnistage.
Prima di poter utilizzare i servizi, gli offerenti che si connettono per la prima volta devono effettuare la procedura di registrazione a cui possono accedere seguendo il link apposito. All’atto della registrazione l’offerente dichiara di accettare i termini e i vincoli imposti dalla licenza d’uso di cui sopra. Deve inoltre indicare il proprio nome, l’indirizzo e-mail ed eventualmente l’indirizzo della propria pagina Web e deve scegliersi un login e una password da utilizzare in tutte le connessioni successive. Dopo aver terminato la registrazione avrà immediatamente accesso al servizio, senza aspettare la convalida dell’amministratore. Sul perché abbiamo operato questa scelta ne discutiamo nella sezione 2.1.
Dopo la prima volta l’offerente accede ai propri servizi seguendo il link "offerente registrato" sulla pagina principale.
Gli studenti non necessitano di una procedura apposita di registrazione in quanto vengono automaticamente inseriti all'avviamento del servizio utilizzando i login già presenti in CariStudenti. Di conseguenza per gli studenti non c’è la stessa differenza che c’è per gli offerenti tra registrati e non registrati.
Sia gli studenti che gli offerenti registrati, prima di accedere alla propria sezione, passano dalla procedura d'identificazione che chiede login e password; in caso di insuccesso verrà visualizzata un'apposita pagina d'errore che riporterà alla pagina principale.
La sezione degli studenti contiene un menu con i seguenti pulsanti:
Qui di seguito descriviamo le scelte una a una.
Quando l’utente segue il collegamento per la modifica competenze, accede a una pagina nella quale viene visualizzata la propria scheda personale, nella quale si trovano tutte le voci delle competenze raggruppate per categoria. Le categorie, da definirsi meglio in fase di realizzazione, saranno almeno quattro: sistemi operativi, applicativi per ufficio, linguaggi di programmazione, lingue conosciute. Uno studente potrà selezionare per ogni voce il livello di conoscenza che ritiene di possedere. Poiché si tratta di autocertificazione, al fine di evitare la possibilità che persone con le stesse conoscenze esprimano giudizi radicalmente differenti, limiteremo a tre i livelli di conoscenza
specificabili, più uno speciale:
Lo studente potrà operare questa scelta selezionando semplicemente col mouse la casella desiderata: sarà semplice come compilare un qualsiasi questionario a crocette. Nel caso in cui vi si acceda per la prima volta i valori delle varie competenze sono settate al valore di default "Non specificata". Quando il livello di conoscenza di una voce è impostato al valore di "Non specificata", lo studente verrà automaticamente escluso dalle operazioni di ricerca su quella determinata voce.
Questo risulta essere di grande aiuto, poiché permette allo studente di selezionare solo il livello di conoscenza per le competenze che conosce, lasciando tutte le altre al valore di default; cosa che è importante nel nostro caso siccome la lista delle competenze sarà molto lunga (decine o forse anche centinaia di voci).
Le voci all’interno delle varie categorie verranno visualizzate in ordine alfabetico, facilitandone la ricerca da parte dello studente.
Nel caso in cui vengano apportate delle modifiche alla propria scheda personale è possibile renderle effettive tramite il pulsante "Aggiorna".
Qualora uno studente decida di non voler più usufruire di CAP si potrà rimuovere dal servizio, tramite un apposito pulsante: per rendere effettiva l’eliminazione sarà necessaria una conferma, al fine di scongiurare la possibilità di un’eliminazione accidentale.
(2) Consultazione bacheca
Si accede alla bacheca elettronica. Questa parte dell’interfaccia è gestita da WebUnistage
(3) Consultazione richieste
Questo pulsante consente l’accesso alla pagina nella quale vengono elencate tutte le richieste ricevute dallo studente. Le richieste sono le e-mail che lo studente riceve dal programma tutte le volte che il suo nome viene selezionato dalla ricerca di un’azienda.
In questa pagina vengono visualizzate in una lista e per ciascuna si riportano le seguenti informazioni:
Per ogni richiesta viene data la possibilità di contattare l’azienda via e-mail e, nel caso in cui sia stato specificato in fase di registrazione, di collegarsi al sito Web.
Uno dei punti di forza di CAP sta nel fatto che, al momento dell’aggiornamento della propria scheda personale, verranno inviate allo studente tutte le richieste che prima non venivano soddisfatte.
È un pulsante che permette di spedire e-mail all’amministratore per proporre suggerimenti e chiedere chiarimenti. L’utilizzo principale per cui l’abbiamo pensato è quello di proporre modifiche sull’albero delle competenze (aggiunte di categorie e di singole competenze).
L’interfaccia descritta, come si può ben vedere, è semplice e intuitiva e le funzionalità offerte tendono ad automatizzare il servizio agevolando gli studenti.
Vediamo ora quali sono le possibilità per un’azienda in cerca di personale che abbia deciso di usufruire di CAP.
Il menu delle aziende permette di fare una delle seguenti scelte:
2.2) ad opera di personale universitario
La pubblicazione di borse di studio e di stage è una cosa di cui si occupa esclusivamente WebUnistage, mentre la pubblicazione di offerte di lavoro riguarda il servizio offerto dal gruppo CAP.Nel primo caso WebUnistage distingue i casi se l’offerente sia personale universitario, nel qual caso la pubblicazione non viene preventivamente controllata dall’amministratore, oppure un’azienda o ente o associazione, nel qual caso la pubblicazione deve preventivamente essere approvata dall’amministratore.
Nel caso della pubblicazione di offerte di lavoro invece il controllo preventivo non viene mai effettuato: questo per facilitare l’accesso ai due servizi (bacheca ed e-mail) da parte di chiunque voglia offrire un lavoro. Di conseguenza. CAP non fa distinzione su chi sia l’offerente, che è semplicemente qualcuno che offre un lavoro.
(1) Pubblicare un’offerta di lavoroQualora un utente prema questo pulsante si troverà di fronte ad una tabella con le voci delle competenze. Questa è esattamente la stessa tabella che abbiamo già descritto per il menu dello studente, con le stesse identiche voci.
Tutte le volte che un’azienda accede a questa pagina il valore di conoscenza di tutte le competenze è sempre impostato a quello di conoscenza "Non specificata".
Inoltre sono presenti due pulsanti:
e una barra grafica, nella quale vengono visualizzati i risultati delle ricerche effettuate.
Un’azienda può a propria discrezione decidere di effettuare una ricerca sulla banca dati: per fare questo basta che imposti, per le sole competenze che desidera, il livello di conoscenza richiesto e prema il pulsante "Esegui".
Verranno a questo punto selezionati tutti gli studenti che possiedono, per ciascuna voce, almeno il livello di conoscenza richiesto. Il risultato della ricerca consiste nel numero di studenti trovati: in realtà non si tratta del numero esatto, ma di un valore approssimato espresso non con un numero, ma con l’utilizzo di una barra grafica.
È importante sottolineare che non vengono mai visualizzati i nominativi degli studenti trovati, in rispetto della loro privacy.
Se il numero degli studenti trovati è molto elevato si può a questo punto raffinare la ricerca impostando ulteriori parametri e rieseguirla. Lo stesso si può fare abbassando il livello di conoscenze richiesto nel caso in cui sia stato trovato un numero basso o nullo di persone. Una volta ottenuti risultati soddisfacenti si premerà il tasto "Testo" e si potrà proseguire.
Un’azienda potrebbe anche desiderare di spedire solamente un messaggio in bacheca senza voler usufruire delle ricerche offerte da CAP. Per fare questo non dovrà far altro che premere il tasto "Testo" senza aver però selezionato nulla nel modulo delle competenze.
L’inserzione del testo è, contrariamente alla compilazione del modulo, obbligatoria; nella progettazione integrata dei due servizi abbiamo infatti deciso di considerare la bacheca come il servizio principale, riducendo l’invio delle e-mail a un servizio accessorio di cui le aziende possono o meno avvalersi. Il motivo per cui abbiamo preso questa decisione è che l’invio delle e-mail può risultare un'operazione impegnativa e un’azienda potrebbe non avere la possibilità o la voglia di utilizzarlo sempre, mentre il servizio della bacheca, con il suo accesso pubblico, arriva immediatamente a un’utenza più vasta senza grandi sforzi da parte dell’azienda.
Come stimolo per l’azienda a utilizzare il nostro servizio, abbiamo comunque deciso di far precedere la pagina della compilazione (opzionale) della tabella a quella della compilazione (obbligatoria) del testo.
Questa possibilità di impaginazione è stata solamente una tra le tante che ci si sono presentate, ma ci è sembrata comunque quella che rendesse l’utilizzo il più intuitivo e funzionale possibile: per motivi di chiarezza e correttezza specificheremo in modo evidente nella suddetta pagina che la compilazione del curriculum con ricerca automatica è facoltativa.
Ma torniamo al momento in cui l’utente preme il pulsante "Testo": se non ha eseguito alcuna ricerca verrà visualizzata una pagina nella quale può inserire il testo da mettere in bacheca. Per la descrizione di questa pagina rimandiamo alla Long Proposal di WebUnistage.
Se l’azienda ha fatto almeno una ricerca, ossia se ha premuto il tasto "Esegui" almeno una volta, appare una pagina nella quale, oltre all’area per inserire il messaggio nella bacheca, compare un testo generato da CAP sulla base delle competenze specificate nell’ultima ricerca effettuata. Impostare i valori delle competenze senza premere il pulsante "Esegui" non è considerata una ricerca. Ad esempio se, dopo aver fatto una ricerca impostando dei valori e premendo il pulsante "Esegui", reimpostiamo i valori con l’intenzione di fare una seconda ricerca ma ci scordiamo di ripremere il tasto "Esegui", quando andiamo a spedire il messaggio il programma tiene conto solo della prima ricerca.
Premendo il pulsante "Invia" CAP si occuperà di inviare il testo in bacheca e, se necessario, le e-mail agli studenti selezionati dalla ricerca. Nel corpo delle e-mail viene inserito il testo dell’annuncio (quello inserito dall’azienda) più il testo generato automaticamente dal programma.
Ribadiamo che l’azienda non sa a quali studenti verrà inviata.
Nella stessa pagina, verrà posta l’avvertenza che il messaggio generato in maniera automatica non è in alcun modo modificabile dall’azienda e che verrà spedito così com’è; l’azienda quindi, nel momento in cui decide di spedire il messaggio, deve essere consapevole di questo.
(2) borse di studio e stage
Per quanto riguarda l’offerta di borse di studio e stage rifarsi alla Long Proposal di WebUnistage.
(3) Spedire una e-mail all'amministratore
Il pulsante "Mail", ha la stessa funzione che ha nel menu degli studenti.
(4) Eliminare tutte le proprie informazioni
Il pulsante "Elimina" ha lo scopo di eliminare dalla banca dati tutte le informazioni riguardanti l’azienda in questione, la quale non potrà più usufruire di CAP se non dopo aver rieseguito la procedura di registrazione.
Poiché l’azienda è la classe di utenza più importante per il successo del sito, spenderemo particolari energie nel tentare di rendere l’interfaccia dal lato azienda il più accattivante possibile, invogliando il più possibile il visitatore occasionale ad usufruire del servizio.
Sia nelle pagine dedicate agli studenti che in quelle dedicate alle aziende inseriremo, ove riterremo opportuno, link alla pagina precedente e pulsanti di cancellazione operazione, in modo da poter agevolare l’utilizzo del sito.
2.1 - Problematiche di amministrazione, di sicurezza e di privacy
2.1.1 - Compiti dell’amministratore
I doveri dell’amministratore sono i seguenti:
(1) controllo preventivo su pubblicazione di stage e borse di studio
Questa è una problematica che compete al gruppo WebUnistage
(2) vigilanza sulle offerte di lavoro
L’offerente può dunque pubblicare annunci riguardanti offerte di lavoro appena terminata la procedura di registrazione. Mentre con gli stage e le borse di studio l’amministratore esercita un controllo preventivo per ogni annuncio, in questo caso non solo il controllo preventivo non viene esercitato sul singolo annuncio, ma neppure sul login dell’offerente.
L’amministratore ha comunque il compito di vigilare sulla bacheca e verificare che vi vengano inseriti annunci consoni al fine per cui è stata realizzata, provvedendo a rimuovere rapidamente ogni messaggio scorretto che vi possa essere pubblicato e, a seconda della gravità, ad ammonire l’azienda che l’ha pubblicato oppure ad eliminare direttamente il login.
Questo meccanismo, che permette all’offerente di utilizzare il servizio fin dalla prima connessione, è stato pensato per invogliare le aziende a usufruirne. Le aziende, senza le quali il servizio perde ogni valenza, sono infatti la classe di utenza più difficile da coinvolgere, per cui ci siamo sforzati, nella progettazione dell’interfaccia, di creare qualcosa che potesse incatenare l’attenzione del navigatore occasionale: obbligando l’offerente ad aspettare giorni in attesa della convalida del login avremmo sicuramente perso l’utenza non fortemente determinata.
Il lato negativo è che va persa una parte dell’affidabilità del servizio: il buontempone che voglia pubblicare un pesce d’aprile può farlo tranquillamente e, se architetta bene lo scherzo, rischia anche di non essere scoperto. Ancora peggio, si può pensare a un folle, o un’orda di folli, che pubblicano ogni genere di sconcezze nella bacheca, con l’amministratore che si affanna a rimuovere gli annunci e i login mentre questi rientrano continuamente con login e password rinnovati.
Soppesando pro e contro, abbiamo ritenuto comunque di correre questo rischio, consci del fatto che nella realtà queste cose non capitano continuamente ma si mantengono al di sotto di una soglia fisiologica e che, se il servizio è ben impostato ed è veramente utile, verrà utilizzato con serietà, con al più una punta di umorismo il primo d’aprile.
Se comunque a servizio già avviato si dovesse rivelare necessaria una maggiore soglia di sicurezza, basterà con un carico minimo di lavoro ristrutturare il progetto in maniera da obbligare l’amministratore a convalidare il login controllando che l’offerente sia chi dice di essere. In questo modo, a costo di una scomodità iniziale, l’offerente potrà riaccedere al servizio in maniera veloce, pubblicando annunci senza controllo preventivo.
Quando gli studenti, le aziende registrate e l'amministratore accedono al servizio tramite i rispettivi link nella pagina principale, si avvia la procedura di autenticazione dell’utente.
Per gestire questa ci avvaliamo di un servizio fornito dal server APACHE, che utilizza il protocollo standard di autenticazione dell'HTTP 1.1.
Il server per regolare l’accesso ad un reame si basa su file di password. Per quanto riguarda gli studenti, utilizzeremo quello già presente per i servizi di CariStudenti; questo approccio, inevitabilmente, esclude gli iscritti al primo anno che ancora non possiedono un account, ma semplifica notevolmente la vita ai loro colleghi degli altri anni che non devono effettuare una registrazione e ricordarsi una password specifica.
Qui di seguito analizzerò la legge n. 675/96 del 31/12/96, comunemente nota come legge sulla privacy, limitatamente agli aspetti che ci riguardano.
Nell’ultimo paragrafo spiegherò sinteticamente cosa significa per noi.
Ambito di applicazione
"La presente legge si applica al trattamento dei dati personali da chiunque effettuato nel territorio dello Stato" (Art. 2).
Il trattamento è " qualunque operazione o complesso di operazioni [… ] , concernenti la raccolta, la registrazione, l'organizzazione, la conservazione, l'elaborazione, […]" (Art.1, Comma 1, lettera b), mentre il dato personale è "qualunque informazione relativa a persona fisica, persona giuridica, ente od associazione, identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione personale" (stesso comma, lettera c)
Da questo articolo si evince che anche conservare una lista di nomi, se non viene fatto per motivi strettamente personali (Art. 3, Comma 1), è un’attività a cui si applica la legge sulla privacy, di conseguenza anche il nostro progetto deve fare i conti con tale legge. Vediamo cosa comporta questo.
Notificazione (Art. 7)
"Il titolare che intenda procedere ad un trattamento di dati personali soggetto al campo di applicazione della presente legge e' tenuto a darne notificazione al Garante" (Comma 1), mentre "la notificazione e' effettuata preventivamente ed una sola volta, a mezzo di lettera raccomandata ovvero con altro mezzo idoneo a certificarne la ricezione […]. Una nuova notificazione e' richiesta solo se muta taluno degli elementi indicati nel comma 4 e deve precedere l'effettuazione della variazione".
Il Comma 4 descrive semplicemente le informazioni che devono essere contenute nella notificazione. Queste sono:
"In caso di cessazione, per qualsiasi causa, del trattamento dei dati, il titolare deve notificare preventivamente al Garante la loro destinazione" (art. 16, comma 1), anche in caso di distruzione (art. 16, comma 2).
La notificazione è un compito a cui, se ho interpretato bene lo spirito della legge, non possiamo sottrarci.
Responsabile e titolare
Il titolare è "la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente, associazione od organismo cui competono le decisioni in ordine alle finalita' ed alle modalita' del trattamento di dati personali, ivi compreso il profilo della sicurezza" " (Art. 1, comma 1, lettera d).
Il responsabile è "la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente, associazione od organismo preposti dal titolare al trattamento di dati personali " (Art. 1, comma 1, lettera e).
"Il responsabile procede al trattamento attenendosi alle istruzioni impartite dal titolare […]" (Art. 8, comma 2). Inoltre "deve essere nominato tra soggetti che per esperienza, capacita' ed affidabilita' forniscano idonea garanzia del pieno rispetto delle vigenti disposizioni in materia di trattamento, ivi compreso il profilo relativo alla sicurezza" (art. 8, comma 1).
"Ove necessario per esigenze organizzative, possono essere designati responsabili piu' soggetti, anche mediante suddivisione di compiti" (art. 8, comma 3).
Infine, "i compiti affidati al responsabile devono essere analiticamente specificati per iscritto" (art. 8, comma 4)". Questo è esattamente quanto ho fatto sopra nel paragrafo relativo alle problematiche sull’amministrazione.
Trattamento, diffusione e comunicazione dei dati
Per una definizione di trattamento si veda sopra.
"[…] il trattamento di dati personali da parte di soggetti pubblici, esclusi gli enti pubblici economici, e' consentito soltanto per lo svolgimento delle funzioni istituzionali, nei limiti stabiliti dalla legge e dai regolamenti" (art. 27, comma 1).
Un servizio come il nostro può, secondo la mia opinione, rientrare a buon diritto tra i compiti istituzionali dell’università.
La comunicazione è "il dare conoscenza dei dati personali a uno o piu' soggetti determinati diversi dall'interessato, in qualunque forma, anche mediante la loro messa a disposizione o consultazione" (art. 1, comma 1, lettera g).
La diffusione è "il dare conoscenza dei dati personali a soggetti indeterminati, in qualunque forma, anche mediante la loro messa a disposizione o consultazione" (art. 1, comma 1, lettera h).
"La comunicazione e la diffusione dei dati personali da parte di soggetti pubblici a privati o a enti pubblici economici sono ammesse solo se previste da norme di legge o di regolamento" (art. 27, comma 3).
Essere ricorsi all’espediente di fare inviare le e-mail senza comunicare o diffondere i dati esula l’università dall’obbligo di stilare un regolamento preciso al riguardo in cui autorizzare la diffusione via Internet.
Modalita' di raccolta e requisiti dei dati personali (art. 9)
Informazioni rese al momento della raccolta (art. 10)
"1. L'interessato o la persona presso la quale sono
raccolti i dati personali devono essere previamente informati per
iscritto circa:
a) le finalita' e le modalita' del trattamento cui sono destinati
i dati;
b) la natura obbligatoria o facoltativa del conferimento dei
dati;
[…]
d) i soggetti o le categorie di soggetti ai quali i dati
possono essere comunicati e l'ambito di diffusione dei dati
medesimi;
e) i diritti di cui all'articolo 13 [vedi sotto];
f) il nome, la denominazione o la ragione sociale e il domicilio,
la residenza o la sede del titolare e, se designato, del
responsabile."
"3. Quando i dati personali non sono raccolti presso
l'interessato, l'informativa di cui al comma 1 e' data al
medesimo interessato all'atto della registrazione dei dati o,
qualora sia prevista la loro comunicazione, non oltre la prima
comunicazione."
Questo articolo, che richiede che l’interessato abbia certe informazioni per iscritto al momento della raccolta dei dati, solleva un quesito di ordine giuridico a cui non sono capace di rispondere: la visualizzazione a video delle informazioni equivale a una comunicazione per iscritto?
Diritti dell'interessato (art. 13)
L’articolo 1 parla dei diritti dell’interessato, che sono:
Cosa significa la legge della privacy per noi
La legge sulla privacy si applica a chiunque intenda trattare dati personali non per scopi personali, quindi chiunque voglia tenere una lista di nominativi ne deve tenere conto.
Noi teniamo qualche dato per le aziende il cui trattamento o cessazione del trattamento non deve essere notificato al garante, essendo le aziende persone giuridiche (art. 26, comma 1).
Per quanto riguarda gli studenti ci appoggiamo alla lista di CariStudenti che conserva login, password e nominativi. In più, teniamo nel nostro database per ogni login una lista di competenze. Le competenze non sono dati sensibili poiché non rientrano nella casistica dell’art.22 atta a definire cosa sia un dato sensibile, per cui tutti gli obblighi relativi ai dati sensibili non ci riguardano.
La lista di CariStudenti è invece a mio avviso soggetta all’obbligo di notifica.
Un altro obbligo a cui siamo sottoposti è quello di informare per iscritto lo studente o l’offerente mentre inseriscono i propri dati (all’atto della registrazione per l’offerente, all’atto della prima connessione per lo studente). Non ci è chiaro, poiché non siamo esperti di diritto, se un’informativa a video, che è scritta e può essere stampata dall’utente, costituisca giuridicamente un’informare per iscritto.
Alle problematiche del consenso scritto non siamo interessati, perché questo deve essere dato per il trattamento, la diffusione e la comunicazione dei dati solo se effettuati da parte di privati o enti pubblici economici (art. 11 e art. 20).
I soggetti pubblici, invece, possono trattare i dati personali per lo svolgimento delle funzioni istituzionali, mentre possono comunicare o diffondere dati personali solo se previsto da leggi o regolamenti. Riteniamo che un servizio come il nostro possa rientrare a buon diritto tra i compiti istituzionali dell’università. Inoltre, il fatto di essere ricorsi al meccanismo dell’invio delle e-mail invece di diffondere via Web i risultati delle query, toglie l’Università dall’imbarazzo di dover approvare un regolamento apposito.
In sostanza: l’Ateneo, che è il titolare in questo caso, dovrebbe notificare la propria lista di nominativi degli studenti in CariStudenti al Garante per regolarizzare la propria posizione.
Per quanto riguarda il nostro progetto, occorre che le informazioni di cui dispone la legge siano date all’atto dell’immissione dei dati per iscritto; occorre vedere se un’informativa a video sia in tal caso sufficiente.
Non dobbiamo raccogliere consensi scritti, possiamo trattare i dati a norma di legge e non abbiamo bisogno di diffondere o comunicare i dati.
Ogni altro aspetto toccato dalla legge (modalità della raccolta dati, figura del responsabile, ecc.) non presenta problemi di sorta, poiché in questi casi i vincoli della legge sono più norme di buonsenso che autentiche restrizioni (si pensi all’obbligo di curare gli aspetti di sicurezza, di porre come responsabile una figura qualificata che sia a conoscenza dei vincoli di legge, e altro ancora).
2.1.4 Descrizione LICENZA D'USO
Nella licenza d’uso si informa che i dati contenuti nella banca-dati sono raccolti, trattati e diffusi con la specifica finalità di avviamento al lavoro, nel pieno rispetto della legge 31 dicembre 1996, n. 675.
Si comunica che i dati forniti dagli studenti sono frutto di autocertificazione, per cui non verranno verificati dai responsabili del servizio, i quali non si assumeranno nessuna responsabilità sulla veridicità dei dati.
Preso atto della finalità del trattamento dei dati contenuti nella banca-dati, l'utente si impegna a rispettare tale finalità e quindi ad utilizzare i dati forniti esclusivamente per le finalità di selezione del personale e di avviamento all'occupazione, in osservanza della legge 31 dicembre 1996 n. 675.
In caso di accerta violazione da parte dell'utente, il responsabile provvederà a inibire ogni successivo accesso alla banca dati.
L’utente dichiara inoltre di essere stato adeguatamente informato, previa lettura del manuale d’uso, sull’utilizzo dell’interfaccia e sui problemi concernenti la privacy
Le norme contenute nella presente licenza d’uso vengono accettate dall'utente selezionando l'opzione "Accettazione del contratto" durante il collegamento al sito
2.2 - Confronto con altre applicazioni esistenti
CAP presenta notevoli somiglianze con un servizio chiamato Almalaurea, il quale è definito come "la banca dati laureati e diplomati del sistema universitario per il mondo del lavoro e delle professioni" (URL: http://almalaurea.cineca.it).In realtà da un’analisi e da un confronto dettagliato emergono sostanziali differenze, che, sotto certi punti di vista rendono CAP un servizio che apporta delle novità. Per capire meglio di cosa si tratta, innanzitutto analizziamo Almalaurea più nel dettaglio descrivendo cos'è esattamente e come funziona agli occhi dell’utente.Almalaurea si basa su una grande banca dati contenente i dati di laureati e diplomati degli atenei aderenti all’iniziativa, tra i quali troviamo quelli di Bologna, Catania, Chieti, Modena, Firenze, Ferrara, Modena, Trieste, Torino...
Le aziende in cerca di personale, potranno consultare questa banca dati, per selezionare persone con determinate caratteristiche: è importante a questo punto sottolineare ulteriormente che un approccio di questo tipo (utilizzato anche da CAP) ha un duplice vantaggio rispetto ai classici annunci di offerte di lavoro, cioè non solo facilita l’accesso dei giovani al mondo del lavoro, ma rende più immediato il contatto con le aziende; è proprio per questo che CAP assume un ruolo molto importante nell’integrare un servizio di bacheca elettronica quale WEBUNISTAGE. L’unione di questi due servizi rende il progetto globale di CAP - WEBUNISTAGE, dal punto di vista appena discusso, sicuramente più completo e flessibile di Almalaurea. Ma torniamo a quest'ultimo.
Tutti i neolaureati o diplomati che appartengono a uno degli atenei partecipanti possono decidere di immettere i propri dati nel database di Almalaurea gratuitamente; per fare questo, al momento della presentazione della domanda di laurea presso la Segreteria della propria Facoltà, dovranno consegnare un questionario compilato in cui vengono richiesti una serie di dati di autocertificazione e di autovalutazione. I primi riguardano sostanzialmente le esperienze lavorative, gli studi fatti all’estero e la posizione rispetto al servizio di leva; per ciò che concerne l’autovalutazione ci sono la conoscenza di lingue estere e di competenze informatiche. Questi dati vengono integrati con dati anagrafici e accademici che vengono definiti "di fonte ufficiale".In conclusione per ogni laureato/diplomato nella banca dati finiscono 111 dati: 10 dati anagrafici, 6 riguardanti gli studi preuniversitari e 24 riguardanti quelli universitari, 8 dati di competenze linguistiche, 11 sugli studi all’estero, 8 per le esperienze lavorative e infine 44 sulle intenzioni e prospettive di studio e lavoro.
Siccome lo scopo di Almalaurea è, tra l’altro, quello di agevolare le aziende nella ricerca del personale "riducendo i tempi d’incontro fra domanda ed offerta di lavoro qualificato", la grande banca dati è destinata ad essere consultata, a pagamento, da aziende in cerca di personale e questo può essere fatto in diverse maniere:
Gli utilizzi che ci interessano, almeno per un confronto diretto con CAP, sono quelli che avvengono tramite Web:
(2) Una azienda registrata, cioè che ha accesso all’intera banca dati, tramite un identificativo può consultare a proprio piacimento il database e visionare tutte le informazioni dei curricula che le interessano. In realtà ci sono varie possibilità di acquisto e di utilizzo, ciascuna con un proprio costo: troviamo infatti un vero e proprio listino dei prodotti; questo però non riguarda il nostro tipo di analisi e non approfondiremo ulteriormente il discorso. Il punto principale è che Almalaurea, dal lato azienda, è un servizio a pagamento al contrario di CAP.(3) Questo tipo di utilizzo, chiamato Self-Service, consiste nel consultare Almalaurea come utente libero, quindi in modo gratuito; dopo aver effettuato una ricerca impostando i criteri di selezione che si desidera, si ottengono informazioni sul numero di candidati che soddisfano la richiesta e la visione dei dati di laurea, senza però alcuna indicazione dei dati personali. Qualora l’utente volesse visionare uno o più curricula completi può acquistarli, senza essere costretto ad acquistarli tutti, come nel punto 2. Ovviamente, il terzo tipo di utilizzo è più adatto a clienti occasionali, ma ha comunque il limite che non si possono acquistare più di 20 curricula: in questo caso, infatti risulterebbe più conveniente l’utilizzo descritto nel punto 2. Per quanto riguarda l’accesso per utenti registrati regolato con password viene utilizzato un meccanismo di protezione del reame gestito automaticamente dal server, che utilizzeremo anche noi, come abbiamo descritto nel punto 2.3.Per quanto riguarda l’interfaccia grafica di Almalaurea la pagina principale presenta un menu con link a altre cinque pagine:
I primi due costituiscono i punti d’accesso ai relativi servizi, il terzo è un link a una pagina in cui vengono presentate delle statistiche sui laureati in Emilia Romagna e un’indagine sull’occupazione. Il quarto permette di accedere alle pagine di documentazione, nelle quali troviamo spiegazioni sul progetto, le tariffe per l’anno in corso, i contratti d’uso e la FAQ. Il quinto è un link alle pagine che contengono informazioni sulle Università aderenti al progetto; è presente anche una breve storia di Almalaurea.In tutto il sito abbiamo spesso riferimenti al rispetto della legge 675/96 sulla privacy individuale che regolamenta la raccolta, la trattazione e la diffusione dei dati personali. Chi vuole inserire i propri dati in Almalaurea deve sottostare a una serie di vincoli legali e burocratici che impongono la consegna di un questionario in segreteria, obbligo a cui gli utenti di CAP non sono tenuti, essendo quest’ultimo un servizio promosso da un ente pubblico, l’Università, al fine di favorire l’ingresso nel mondo del lavoro ai propri studenti, compito che rientra nelle sue funzioni istituzionali (vedi capitolo sulla privacy).Almalaurea presenta poi una pagina in cui è spiegato il contratto d’uso per il Servizio Self-Service, contratto a cui ci siamo ispirati scrivendo la licenza d’uso di CAP.Per quanto riguarda l’interfaccia grafica, abbiamo potuto vedere solo quella per il servizio Self-Service, anche se è possibile intuire che quella per il servizio abbonati sia praticamente identica. Si tratta di una pagina multiframe: in un frame di impostazione quasi tabellare è possibile impostare una query selezionando i criteri richiesti, che è esattamente ciò che avevamo già scelto per CAP; nel secondo frame vengono visualizzati i risultati della query, cioè il numero di persone che hanno le caratteristiche selezionate, come in CAP. Noi abbiamo però scartato l’idea del multiframe perché le nostre esigenze sono lievemente diverse; dobbiamo infatti considerare anche che abbiamo una casella di testo da riempire obbligatoriamente, quindi dopo aver analizzato svariate possibilità abbiamo scelto di strutturare la pagina in maniera particolare (vedi sezione 2.0).
Le differenze tra CAP e Almalaurea sono molte: sicuramente quella che risulta più evidente ad uno sguardo veloce e che abbiamo già accennato è che CAP è un servizio completamente gratuito, mentre Almalaurea è a pagamento (almeno dal punto di vista di chi vuole consultare i curricula).
Inoltre, per i motivi che abbiamo spiegato sopra, CAP è un servizio completamente su Web e i suoi utenti non devono sottostare a noiose procedure burocratiche che li obblighino a consegnare documentazione cartacea in un qualche ufficio, cosa che rende il suo utilizzo occasionale molto più pratico e veloce.
Ancora, in Almalaurea non si tiene molto conto delle conoscenze e delle competenze dei neolaureati, perché si tratta di un servizio rivolto a varie facoltà e corsi di laurea. CAP invece, essendo rivolto solamente agli studenti di Informatica, pone enfasi proprio sulle loro conoscenze specifiche, e non tanto sulla loro storia passata accademica o lavorativa. Questo è rilevante perché permette alle aziende di poter selezionare personale ad hoc per ogni esigenza, cosa che è molto importante nell’ambito informatico, così vasto e mutevole.CAP assomiglia molto al servizio Self-Service di Almalaurea, specie nel fatto che come risultato di una query abbiamo il numero di studenti che la soddisfano; la differenza sta nel fatto che in CAP non è possibile in alcun modo la visione delle competenze e non si può sapere chi è stato selezionato: si può però decidere di contattare questi studenti con la semplice pressione di un pulsante spedendo un messaggio; il grande punto di forza sta nel fatto che uno studente,
se vorrà, potrà rimanere nell’anonimato.
Un altro punto a favore di CAP è quello riguardante l’aggiornamento dei dati: allorché uno studente decida di aggiornare il proprio curriculum, in CAP, può farlo tramite Web in qualsiasi momento tramite semplicissime e veloci operazioni; per quanto riguarda Almalaurea, invece, per ora questo non è possibile, ma sembra che prossimamente verrà sviluppato un apposito sistema di aggiornamento su Internet. Bisogna comunque dire che i dati trattati da Almalaurea difficilmente necessitano di aggiornamenti, mentre in CAP la modifica delle competenze informatiche risulta essere relativamente frequente soprattutto perché CAP, al contrario di Almalaurea è un servizio destinato a studenti che, quindi, nel corso del tempo sono destinati ad arricchire le proprie conoscenze.
2.3 - Risorse, metodologie e tecnologie utilizzate
Lo schema si propone di presentare in maniera formale la mappa del sito esemplificandone l'interfaccia grafica e la struttura logica.
Abbiamo pensato di utilizzare un formalismo ispirato dagli automi a stati finiti:
I commenti in bold sulle transizioni sono note informali che aiutano a comprendere meglio lo schema.
Visto che si tratta di un servizio Web accessibile tramite il server CariStudenti, CAP sarà composto da pagine HTML con script CGI che controllano il flusso d'esecuzione e l'interfacciamento con un DBMS.
Si può notare che gli stati dell’automa dello schema sopra riportato sono le pagine Web già ampiamente descritte nel punto 2.0.
Ora descriveremo nel dettaglio la navigazione attraverso le pagine di CAP, non più dal punto di vista dell’utente, ma da quello del progettista analizzando nel dettaglio cosa succede a basso livello, quando vengono eseguite le varie operazioni e premuti i pulsanti. Nel fare questo non accenneremo più alle parti riguardanti WebUnistage, ad esempio non parleremo più dei link per accedere alle borse di studio...
Quando gli studenti , le aziende registrate e l'amministratore accedono al servizio tramite i rispettivi link nella pagina principale, si avvia la procedura di autenticazione dell’utente.
Per gestire questa ci avvaliamo di un servizio fornito dal server APACHE, che utilizza il protocollo standard di autenticazione dell'HTTP 1.1.
Quando l’utente accede ad uno dei servizi protetti (vedi schema generale) di CAP (dalla home page) la procedura d'autenticazione si preoccuperà di fornire una form in cui vengono chiesti login e password che verranno poi verificati dal server.
Una volta fatta questa procedura sarà APACHE che, in una variabile d'ambiente CGI, si terrà traccia dell'identità dell'utente durante tutto il periodo della connessione; in questo modo in tutte le pagine "sottostanti" (reame) non sarà più necessario richiedere l’autenticazione.
Il server per regolare l’accesso ad un reame si basa su file di password. Per quanto riguarda gli studenti utilizzeremo quello già presente per i servizi di CariStudenti, mentre per le aziende ne creeremo uno nostro, che verrà aggiornato in maniera automatica al momento in cui esse si registreranno.
Per il fatto che per gli studenti utilizzeremo un file di password già esistente, come abbiamo già accennato nel punto 2.0, gli studenti non necessitano di registrazione, con implicazione che tutti gli studenti verranno inseriti nel database al momento della attivazione del servizio.
Finché non avranno modificato la scheda personale, comunque, non riceveranno alcuna richiesta. Ma di questo ne parleremo meglio in seguito.
Ora, prima di descrivere l’implementazione dei servizi riteniamo opportuno spiegare l'organizzazione del database su cui essi si basano.
STRUTTURA DATABASE:
Partiamo descrivendo le entità di base STUDENTI e AZIENDE. Per gli STUDENTI vogliamo rappresentare i seguenti dati: il login e l’indirizzo e-mail (attributi Login e E-mail).
Per le AZIENDE teniamo conto del login e dei dati utili per contattare dell’azienda, ragione sociale, e-mail e sito Web, che corrispondono ai seguenti attributi:
Per entrambi l’attributo login è quello da loro usato per la procedura di autenticazione.
L’entità COMPETENZE contiene la lista delle voci delle competenze e le relative categorie di appartenenza: Competenza_Id, Categoria (Es: la voce "C++" ha come categoria "Linguaggi di programmazione").
A questo punto introduciamo l’associazione Voto che ci permette di determinare la scheda personale di ogni studente associando ad ogni competenza un livello di conoscenza (attributo Voto).
STUDENTI-Voto=0,n => ogni studente può avere più competenze. Lo 0 significa che o non ha mai modificato il proprio curriculum, oppure si è cancellato dal servizio.
COMPETENZE-Voto=0,n => più studenti possono avere la stessa competenza, oppure una competenza può non essere posseduta da nessuno studente.
Ogni volta che una azienda fa una richiesta, tramite query, a quest'ultima le viene associato un codice che si trova nell’entità RICHIESTE (ha come attributi Richiesta_Code e Richiesta_Text il quale contiene il testo spedito in bacheca associato alla query).
Nel caso in cui non venga formulata una query, ma spedito soltanto un messaggio in bacheca, questo non verrà memorizzato nel database, ma verrà gestito solamente da WebUnistage.
Tramite l’associazione Az_Req abbiamo la data (attributo Data).
AZIENDE-Az_Req=0,n =>un'azienda può registrarsi senza usufruire del servizio.
RICHIESTE-Az_Req=1,1 =>ogni richiesta è relativa ad una sola azienda.
L’associazione Stud_Req tiene conto delle richieste ricevute da ciascuno Studente.
STUDENTI-Stud_Req=0,n => uno studente può non aver ricevuto alcuna richiesta.
RICHIESTE-Stud_Req=1,n => una richiesta può coinvolgere più studenti.
Per tener traccia delle competenze associate ad ogni richiesta introduciamo l’associazione Comp_Req, che contiene l’attributo Voto che tiene conto del livello di esperienza richiesto dall’azienda.
COMPETENZE-Comp_Req=0,n=> Una competenza può non essere richiesta da nessuna azienda.
RICHIESTE-Comp_Req=1,n =>Una azienda richiede almeno una competenza.
L’associazione Stud_Req risulta essere ridondante (notare che si crea un ciclo), poiché le stesse informazioni possono essere ricavate tramite le associazioni Voto e Comp_Req, ma abbiamo deciso di mantenerla: la maggiore occupazione di memoria è giustificata dai vantaggi ottenuti in termini del numero di accessi.
SCHEMA RELAZIONALE
STUDENTI (Login, Email)
AZIENDE (Azienda_Id, Azienda_Name, Azienda_Email, Azienda_Web)
COMPETENZE (Competenza_Id, Categoria)
RICHIESTE (Richiesta_Code, Richiesta_Text, Azienda_Id, Data)
VOTO (Login, Competenza_Id, Voto)
STUD_REQ (Login, Richiesta_Code)
COMP_REQ (Competenza_Id, Richiesta_Id)
Lo schema è in terza forma normale: si può vedere ad esempio che la tabella COMPETENZE, pur essendo composta soltanto della chiave, è stata mantenuta solamente per rispettare le forme normali, per evitare di perdere traccia delle voci che non sono associate a nessuno studente.
OPERAZIONI SUL DATABASE
Le operazioni effettuate sul database sono:
Preferiamo comunque non descrivere ora queste operazioni nel dettaglio, ma lo faremo mano a mano che le incontreremo durante la nostra navigazione. Torniamo quindi al momento in cui un utente registrato riesce, dopo l’identificazione, ad accedere al proprio menu.
Se ad accedere al servizio è l'amministratore di sistema attraverso le pagine dedicate descritte nel punto 2.0 potrà effettuare due operazioni:
1- Eliminare un messaggio dalla bacheca
2- Eliminare un utente offerente
Nel primo caso la gestione è rimandata a WebUnistage che aggiornerà il nostro database attraverso l'operazione nove : tutti i dati delle richieste in questione verranno eliminati dalle tabelle COMP_REQ, STUD_REQ e RICHIESTE.
Nel secondo caso viene eliminato l'offerente dal database attraverso l'operazione 6: tutti i dati relativi all’azienda in questione verranno eliminati dalla tabella AZIENDE e così tutte le richieste che aveva effettuato (tabelle RICHIESTE e STUD_REQ).
Nel caso si tratti di uno studente, avrà la possibilità di modificare la propria scheda personale o di visionare le richieste che gli sono personalmente pervenute.
Se decide di modificare la propria scheda personale, il CGI, invocato tramite la pressione del pulsante "Inserimento competenze" di tipo Submit, si occuperà di interrogare il database (operazione 1): dalla tabella COMPETENZE estrarrà tutte le possibili competenze e da quella VOTO estrarrà le competenze con i relativi livelli di conoscenza per lo studente in questione, e si occuperà di generare una pagina HTML. Abbiamo già detto che, per motivi di comodità di utilizzo, le voci all’interno di ogni categoria verranno visualizzate in ordine alfabetico.
Per la creazione della pagina abbiamo previsto due possibilità:
La prima volta che uno studente accederà a questa pagina i valori di tutte le competenze saranno inizializzati a conoscenza "Non specificata".
Questo è un valore particolare poiché, tutte le voci con tale valore non saranno in realtà inserite nella tabella voto, ma saranno inserite solo quelle che verranno modificate. Abbiamo deciso di fare questo altrimenti tale tabella, sarebbe diventata ben presto ingestibile, a causa dell’enorme mole di dati.
In questa pagina lo studente avrà la possibilità di apportare della modifiche alla propria scheda personale, oppure, eliminare tutti i propri dati dal database.
Se apporterà delle modifiche ai valori delle competenze, premendo il pulsante "Aggiorna" di tipo Submit, potrà renderle effettive. Verrà invocato un CGI che si occuperà di fare l’operazione 2: consiste nell’aggiornare la tabella VOTO, in base ai nuovi valori.
Una volta aggiornato il database, automaticamente verranno fatte una serie di query, per vedere se le nuove competenze impostate sono in grado di soddisfare richieste già fatte, memorizzate nel database. Per fare ciò, per ognuna di queste (tabella RICHIESTE), attraverso le tabelle COMP_REQ e VOTO verrà verificato se lo studente possiede le competenze necessarie. Se ne vengono soddisfatte di nuove, la tabella STUD_REQ verrà aggiornata e verranno spedite allo studente le e-mail opportune. Per i dettagli sulla spedizione di queste e-mail vedere più avanti nelle funzionalità per le aziende.
Se lo studente decide di eliminare tutti i propri dati dal database, deve premere l’apposito pulsante, sempre di tipo Submit. Verrà eseguita l’operazione numero tre: tutte le tuple delle tabelle STUD_REQ e VOTO nelle quali compare lo studente saranno eliminate. Quindi per lo studente in questione, la situazione viene riportata a quella dell’inizializzazione del sistema. Cioè lo studente rimane ancora presente nella tabella STUDENTI e il file di password non viene modificato, in modo che in qualunque momento potrà tornare ad usufruire del servizio.
Ma torniamo al menu studente. Da questo potrà, se lo desidera, decidere di accedere alla pagina per la visualizzazione delle richieste. Nel momento in cui premerà il pulsante "Consulta richieste" il CGI interrogherà il database (operazione 4): analizzerà la tabella STUD_REQ per risalire ai codici delle richieste ricevute, con i quali, dalla tabella RICHIESTE, si ottiene il messaggio associato a ciascuna richiesta e tutti i dati delle aziende in questione. Inoltre dalla tabella COMP_REQ si ricavano le competenze richieste per ogni messaggio. Tutte le informazioni ottenute, vengono poi visualizzate in un’apposita pagina, la cui struttura è già stata trattata nel punto 2.0.
A questo punto ripetiamo la navigazione supponendo che ora l’utente sia un’azienda, che debba effettuare le procedura di inizializzazione. Una volta seguito il link "Non registrato", appare una form con i seguenti campi: "Login", "Password", "Ragione sociale", "E-mail", "Sito Web". Un’azienda dovrà riempire i primi due campi scegliendosi un login e una password da utilizzare in tutte le connessioni successive. Il campo "Sito Web" è l’unico ad essere opzionale.
Premendo il pulsante "Ok", il CGI invocato si occuperà di verificare che la form sia stata compilata correttamente. In tal caso l’azienda verrà inserita nel database (operazione 5): tutti i dati che sono stati immessi nella form vengono inseriti nella tabella AZIENDE e il file di password delle aziende viene opportunamente modificato. Inoltre viene automaticamente spedita una e-mail
all’amministratore di sistema, contenete i dati dell’azienda, il quale dovrà verificare la veridicità di questi dati. Se verranno riscontrate dichiarazioni false, egli dovrà eliminarne i dati e i messaggi effettuati attraverso l’apposita interfaccia sopra descritta.
A questo punto si accede al menu delle aziende registrate. Un’azienda può decidere se eliminare tutti i propri dati dal database o se seguire il link per le offerte di lavoro.
Nel caso voglia fare la prima scelta, premuto il pulsante "Elimina", il CGI invocato si occuperà dell’operazione numero sei sul database, già descritta sopra.
Se volesse invece inoltrare un’offerta di lavoro, dopo aver seguito il link "Offerte di lavoro" apparirà una pagina nella quale ritroviamo la tabella delle competenze che avevamo visto per lo studente. Questa presenterà tutti i valori delle voci inizializzati a "Non specificata".
Ogni volta che un’azienda accederà a questa pagina la tabella sarà sempre uguale (vuota), per cui essa non viene creata dal CGI, come succedeva per gli studenti (infatti ci si accede tramite link e non tramite un pulsante). Quindi la tabella delle competenze è semplicemente una lista di checkbox.
Siccome la formulazione della query è opzionale, manteniamo una variabile che ci indica in ogni momento se almeno una query è stata eseguita. Questo ci servirà per decidere quale pagina visualizzare per l’inserimento del testo. (Vedi 2.0).
Se l’azienda vuole inserire solamente il testo, non compilando la form della query, premendo il tasto "Testo", viene visualizzata la pagina relativa all’inserimento del solo testo.
Se invece, vuole eseguire anche una query, selezionerà i valori desiderati, e potrà eseguirla premendo il pulsante "Esegui". Questo avrà l’effetto di richiamare il CGI ed eseguire l’operazione numero 7 sul database: si effettua una ricerca sulla tabella VOTO e vengono restituiti tutti gli studenti che possiedono per tutte le competenze definite nella form con un valore maggiore o uguale a quello richiesto. Tutte le voci che hanno il valore "Non specificata" vengono automaticamente scartate dal CGI in fase di creazione della query. Siccome la memorizzazione delle richieste avviene soltanto dopo l’invio del testo, al fine di tenere traccia dell’ultima query effettuata, le competenze richieste vengono memorizzate in un’area di memoria temporanea, solamente se sono state modificate delle voci.
In questo caso verrà anche aggiornata la variabile descritta sopra.
A questo punto premendo il pulsante "Testo", se la variabile indica che è stata eseguita almeno una query si accede alla pagina di immissione testo in bacheca da associare alla query.
Premendo "Invia" si compierà l’ultimo passo che era necessario per completare l’offerta di lavoro.
Il CGI invierà oltre al messaggio in bacheca, un’e-mail a tutti gli studenti che erano stati trovati nell’ultima query effettuata e andrà ad aggiornare il database (operazione 8): viene associato alla richiesta un codice, generato dal CGI, e inserito, assieme al testo, nella tabella RICHIESTE. Vengono inoltre aggiornate la tabella COMP_REQ in base alle competenze richieste e la tabella STUD_REQ in base agli studenti trovati.
Vi sono due possibili modi di strutturare gli script CGI indicati: o implementarne uno unico che si occupi dell'intero servizio, oppure uno associato ad ogni funzionalità offerta, che ne abbia bisogno.
Nel primo caso sarà necessario mantenere lo stato di navigazione, in modo che lo script possa prendere delle decisioni in base all'azione compiuta e allo stato in cui ci si trova. Visto che gli script non permettono di fare ciò, verrà realizzato attraverso campi hidden. Comunque la scelta è rimandata alla fase implementativa.
Abbiamo accennato più volte e in vari contesti della spedizione automatica e non, di e-mail: vediamo un po’ meglio come pensiamo di realizzarle.
Per la spedizione di e-mail verso offerenti e amministratore abbiamo deciso di utilizzare un’apposita form HTML con i seguenti campi: "TO:", "SUBJECT:", "CONTENT:". Il campo "TO:" viene automaticamente inizializzato a seconda del contesto in cui ci si trova:
Parliamo ora delle e-mail automatiche.
Agli studenti selezionati da una query verrà spedita una e-mail contenete il testo scritto dall'offerente, il quale, come abbiamo già visto più volte, verrà messo anche in bacheca (vedere WebUnistage), più un testo che rappresenta la query che viene creato in maniera automatica.
La spedizione e la creazione delle e-mail avviene ad opera di un apposito CGI, in modo totalmente trasparente all’azienda.
Il testo generato a partire dalla query consiste in 2 parti:
N.B. Quando un'azienda sceglie di inviare le e-mail agli studenti, implicitamente si impegna ad accettare il testo generato in modo automatico dalla query, che viene visualizzato in un’area di testo non modificabile. Comunque rimane implicita la possibilità di comunicare con l’amministratore per eventuali chiarimenti o proposte (anche di modifica).
Un concetto importante, è quello che CAP deve essere altamente sincronizzato con WebUnistage, quindi, ogni messaggio che viene cancellato nella bacheca elettronica deve anche essere cancellato dal database di CAP.
Notare che nel nostro database vengono memorizzati solo i messaggi che allegano sia il testo che la query, per cui sono solo questi i dati condivisi dai due progetti. Per cui la sincronizzazione delle cancellazioni è necessaria solo su questi.
Abbiamo, per ora, deciso di cancellare ogni messaggio dopo un anno dalla data in cui viene inserito. Questo verrà fatto l’ultimo giorno di ogni mese tramite l’operazione numero nove già illustrata sopra.
Visto che i dati condivisi sono in numero molto limitato abbiamo scelto, per semplificare il database, di mantenere due strutture dati diverse per i due progetti, replicando così le informazioni comuni.
3.1 - Descrizione strutturata del lavoro in moduli
Abbiamo deciso di suddividere il lavoro complessivo in otto moduli. Li elenchiamo in una lista in base all' ordine temporale in cui abbiamo deciso di implementarli.
Modulo |
Data inizio |
Data fine |
Durata in giorni/uomo |
| 1 | 01 Feb | 08 Feb | 10 |
| 2 | 22 Feb | 27 Feb | 5 |
| 3 | 24 Feb | 05 Mar | 7 |
| 4 | 08 Mar | 20 Mar | 12 |
| 5 | 01 Apr | 15 Apr | 10 |
| 6 | 01 Apr | 10 Mag | 30 |
| 7 | 10 Mag | 20 Mag | 15 |
| 8 | 20 Mag | 30 Mag | 10 |
3.2 - Forme di interazione tra i gruppi e scadenze coordinate
Per quanto riguarda le parti di interazione con WebUnistage, al momento della valutazione intermedia dovremo aver realizzato le pagine HTML comuni. L' unica altra interazione prevista sara' alla fine, quando riuniremo i due progetti e realizzeremo le ultime operazioni che necessitano di una sincronizzazione (vedi punto 2.3). Quindi i momenti di interazione non sono molti, poiche' i due servizi sono quasi paralleli, e non ce n' e' uno vincolante per l' altro. Abbiamo inoltre tentato, gia' in fase di progettazione, di mantenere i due progetti distaccati (dal punto di vista implementativo) per motivi di semplicita', senza togliere pero' all' utente una visione unitaria del servizio.
3.3 - Stato di avanzamento del progetto previsto a fine marzo
Al momento della valutazione intermedia avremo realizzato i primi quattro moduli descritti nel punto 3.1