RAD: Correzioni dei requisiti individuate dalla Prof

[GoogleCodeExporter]

Fare riferimento agli artefatti in questione.
RAD 3.0

Descrivere dettagliatamente il problema.
I problemi si possono dividere in tre aree:
1. Gestione iscrizioni 
2. Gestione classi
3. Gestione notifiche

Parto dal 3°, ovvero GESTIONE NOTIFICHE.
Il sistema dovrebbe consentire la visualizzazione di notifiche interne.
Ad esempio ci dovrebbe essere, per i seguenti attori, un'interfaccia di 
"Visualizza notifiche" almeno per: DELEGATO DEL RETTORE, IMPIEGATO e DIRETTORE.
Questo perché evidentemente non basta che gli attori sopra citati ricevano le 
email come notifica, ma devono riceverla NEL sistema e devono poter agire di 
conseguenza NEL SISTEMA. Questa visualizzazione delle notifiche quindi 
comprende ad esempio la visualizzazione delle notifiche di LICENZIAMENTO (di un 
impiegato da parte di un altro impiegato), nell'interfaccia del DELEGATO DEL 
RETTORE.
Insomma tutte le notifiche via mail che riguardano la gestione dovrebbero 
essere visualizzate anche in questa interfaccia, oltre che per email.
Potrebbe quindi esserci una entità "NotificaGestione" con un attributo TIPO 
che distingue i tipi di notifica.

Passiamo ora alla 1, ovvero la GESTIONE ISCRIZIONI.
Noi gestiamo la domanda di iscrizione in un solo passo in cui chiediamo vari 
dati anagrafici, i dati di servizio e una specie di "liberatoria" sullo stato 
di salute del bambino. Successivamente diamo un tempo a chi è stato accettato 
di "ritirarsi" per far scorrere la gradutoria, la quale dopo quel tempo diventa 
definitiva.
In realtà ciò che succede non è questo.
Il RAD va modificato per supportare questa procedura:

a. Il genitore compila la domanda di iscrizione con i dati ANAGRAFICI e dati 
richiesti per il calcolo PUNTEGGIO nel bando come "Distanza dall'asilo", 
reddito, etc (che noi non gestiamo attualmente). La domanda dovrà consentire 
il SALVATAGGIO, cioè dato che questi campi sono davvero tanti, deve poter 
essere "memorizzata" e "ripresa" dall'utente nel caso debba allontanarsi dal 
computer. 
In questa fase NON DEVONO essere richiesti dati del servizio come il tipo di 
pasto/servizio richiesto, o certificazioni sulla salute del bambino.

b. Alla scadenza del bando, i punteggi vengono calcolati a parte (magari con un 
file excel) e inseriti nel sistema come abbiamo già previsto.

c.Una volta scaduto il termine per il ritiro delle domande, viene effettuata 
l'iscrizione vera e propria. Quindi il GENITORE deve compilare un altro modulo 
che chiede il tipo di servizio richiesto, la situazione sanitaria del bambino 
(vaccinazioni, malattie passate) e chiede di recapitare i certificati delle 
vaccinazioni, delle malattie e di consegnare una liberatoria firmata per la 
tutela dei dati per la privacy (che immagino sarà scaricabile).

d. Una volta scaduto il termine per le iscrizioni all'asilo, l'IMPIEGATO dovrà 
avere una visualizzazione delle iscrizioni non interamente convalidate e, 
un'iscrizione alla volta, convalidare che per quell'iscrizione sono stati 
consegnati (a mano in segreteria) i seguenti documenti firmati dal genitore:
-Certificati delle vaccinazioni (o autocertificazione che liberi l'asilo dalla 
responsablità),
-Certificato delle malattie contratte dal bambino in passato,
-La liberatoria per la privacy.

Quindi l'impiegato per ognuna di queste voci avrà tipo un flag da inserire 
[SI] [NO] [RIFIUTA LA CONSEGNA], e alla fine quando tutti saranno messi a SI 
potrà convalidare l'iscrizione del bambino.
Il bottone di "RIFIUTO" indica che il genitore non vuole vaccinare il bambino 
per scelte personali, ma l'asilo può ritenere di accettarlo lo stesso, senza 
assumersene la responsabilità.

A questo punto i bambini saranno tutti "accettati" dall'asilo ma non saranno 
assegnati ad alcuna CLASSE.

E questo ci porta al punto 2, la GESTIONE CLASSI.
Noi già al momento inseriamo, cancelliamo classi e assegnamo bambini ad una 
classe. Ciò che non facciamo, invece, è:
1. Assegnare un docente alla classe (manca ancora il caso d'uso credo)
2. In questo caso, la professoressa vorrebbe che:
a) L'interfaccia di assegnazione dei bambini sia ordinata per età (crescente o 
decrescente immagino sia indifferente)
b) quando tutti i bambini sono stati assegnati ad una classe, tutta 
l'assegnazione deve venire "inviata" in blocco al DELEGATO DEL RETTORE tramite 
una email E una notifica. Il DELEGATO visualizza la notifica e conferma o 
rigetta l'assegnazione.
Da quì in poi la professoressa non è stata chiara quindi immagino che il 
delegato possa rispondere alla notifica, creando una notifica per l'impiegato 
con la correzione, avvertendo anche l'impiegato via mail.
L'impiegato può quindi riassegnare i bambini alle classi secondo le correzioni 
apportate dal DELEGATO, e riparte quindi il caso d'uso di assegnazione delle 
classi ai bambini. Viene inviata una nuova notifica al DELEGATO, che accetta 
l'assegnazione e questa viene "resa effettiva" nei dati dei bambini.

LINDA sarà la vostra referente per questo task, anche se io sarò sempre 
contattabile per chiarimenti.

Chiaramente vorrei che alteraste di conseguenza anche la suddivisone in 
sottosistemi dell'SDD.

Elencare, se disponibili, eventuali possibili soluzioni.
Ciò che è stato descritto sopra.
Scrivete quì chi si occuperà di quale parte delle modifiche, e vorrei che 
iniziaste da subito.

Persone assegnate
Elisa D'Eugenio
Andrea Micco

Scadenza
24/11 ore 19.00, ma capite che siamo già fuori tempo massimo, quindi anche per 
ADESSO sarebbe perfetto. :)

Original issue reported on code.google.com by funfor...@gmail.com on 21 Nov 2012 at 7:45

• Blocking: #45

[GoogleCodeExporter]

Aggiungo alfonso piscitelli e angelo scafuro che si stanno occupando delle 
interfacce

Original comment by hilin...@gmail.com on 21 Nov 2012 at 7:49

[GoogleCodeExporter]

Mi sto accupando del punto 2 Gestione classi. Ho aggiunto 4 nuovi UC e 
modificato i relativi UCD.

Original comment by ferdi...@gmail.com on 23 Nov 2012 at 4:23

[GoogleCodeExporter]

Mi sto occupando della gestione delle iscrizioni e volevo inserire la questione 
del "salvataggio parziale" della domanda nei requisiti funzionali, così da 
poter creare soltanto gli use cases relativi alla doppia domanda di iscrizione. 
Aspetto che qualcuno mi dia la conferma e mi dica dove inserire questa cosa nei 
requisiti, in cui noto che non è stata esplicitata la possibilità di 
iscrizione.

Original comment by yuri...@gmail.com on 23 Nov 2012 at 7:45

[GoogleCodeExporter]

Altro dubbio esistenziale: 
http://www.unisa.it/vivere_il_campus/asilo/iscrizioni/index qui sono distinti 
tre tipi differenti di domande a seconda della tipologia di utenza, mi tocca 
gestirle tutte e 3 scrivendo 3 use cases differenti e compagnia cantando?

Original comment by yuri...@gmail.com on 23 Nov 2012 at 7:48

[GoogleCodeExporter]

>>mi tocca gestirle tutte e 3 scrivendo 3 use cases differenti e compagnia 
cantando?
-Assolutamente no

>>Mi sto occupando della gestione delle iscrizioni e volevo inserire la 
questione del "salvataggio parziale" della domanda nei requisiti funzionali, 
così da poter creare soltanto gli use cases relativi alla doppia domanda di 
iscrizione
-Metti un unico UC dove dici che salva i dati appena inseriti. 

Original comment by hilin...@gmail.com on 23 Nov 2012 at 7:57

[GoogleCodeExporter]

Quindi l'UC relativo all'iscrizione lo lascio così o comunque differenzio i 
due use cases relativi alla doppia iscrizione? Come unifico i tre tipi di 
iscrizione in un unico UC se molti campi sono differenti?

Original comment by yuri...@gmail.com on 23 Nov 2012 at 8:22

[GoogleCodeExporter]

Ma perchè parli della doppia iscrizione non capisco che intendi per doppia 
iscrizione.
L'iscrizione una è :D

Original comment by hilin...@gmail.com on 23 Nov 2012 at 9:03

[GoogleCodeExporter]

Riporto un po' quello che ho fatto e quello che non so se devo fare:

- creta nuova cartella per gli UC di Gestione Notifiche
- creati UC all'interno di gestione notifiche che si occupano delle varie 
notifiche (eventi, licenziamneto, classi) più uno UC generico (inclusione 
funzionale)
- modificato lo UCD del team3->eventi in quanto lo UC notifica_eventi non è 
più presente nella cartella
- creato nuovo UCD per la gestione delle notifiche
- aggiornato lo UCD generale
? per fare i mockup avrei bisogno di sapere in che modo si vuole rappresentare 
la visualizzazione delle notifiche?
- inserito il dizionario dei dati per il pacchetto
- modificato Class Diagram Completo, aggiunta notifica
? non ci sono da aggiungere anche sequenca diagram e statechart diagram. giusto?

Questo per quanto riguarda il RAD.. per l'SDD e l'ODD chiedo cosa fare e lo 
faccio eventualmente domani:
- inserimento entità notifica all'interno del diagramma ER?
- inserimento nelle tabelle descrittive delle entità?
- modifca anche del documento schema logico?
- inserimento di gestione notifiche nei Servizi dei sottosistemi
- inserimento di gestione notifiche in component diagram, pacchetti e divisione 
sottosistemi?
- modifica pacchetti e control per inserimento di notifiche

Visto che principalmente la modifica era per il RAD io ho modificato fino a 
lì, descrivendo nello specifico cosa ho cambiato per rendere facile un 
controllo, poi per SDD e ODD attendo ordini. Devo moficare questi punti? Devo 
modificarne solo alcuni o nessuno? Ce ne sono alcuni che ho dimenticato? Sono 
modifiche che non impiegano troppo tempo, le posso fare domani prima di ora di 
pranzo se non è un problema

Original comment by elisa.de...@gmail.com on 24 Nov 2012 at 2:43

[GoogleCodeExporter]

Linda, con doppia iscrizione mi riferisco a questo:
"Il genitore compila la domanda di iscrizione con i dati ANAGRAFICI e dati 
richiesti per il calcolo PUNTEGGIO nel bando come "Distanza dall'asilo", 
reddito, etc (che noi non gestiamo attualmente). 
[...]
Una volta scaduto il termine per il ritiro delle domande, viene effettuata 
l'iscrizione vera e propria. Quindi il GENITORE deve compilare un altro modulo 
che chiede il tipo di servizio richiesto, la situazione sanitaria del bambino 
(vaccinazioni, malattie passate) e chiede di recapitare i certificati delle 
vaccinazioni, delle malattie e di consegnare una liberatoria firmata per la 
tutela dei dati per la privacy (che immagino sarà scaricabile)."

Original comment by yuri...@gmail.com on 24 Nov 2012 at 9:26

[GoogleCodeExporter]

Risolta tutta la questione per gli UC: ho separato le tre tipologie di 
iscrizione (come già fatto nei precedenti use cases) ed ho inserito l'UC per 
il completamento delle iscrizione (dubbio: deve includere le precedenti 
tipologie di iscrizione? in questo caso, serve un generico per le tre 
iscrizioni?).
Ho inserito poi l'UC per visualizzare le iscrizioni non convalidate e quello 
per convalidare le iscrizioni.
Provvedo ad effettuare le altre modifiche nel RAD.

Original comment by yuri...@gmail.com on 24 Nov 2012 at 10:54

[GoogleCodeExporter]

Altro dubbio: a questa fase della progettazione è strettamente necessario 
realizzare i nuovi mock-ups per le modifiche appena implementate?

Original comment by yuri...@gmail.com on 24 Nov 2012 at 10:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Aggiornato il dizionario dei dati. Aspetto direttive per SDD e ODD, dove le 
modifiche relative all'iscrizione mi sembrano minori.

Original comment by yuri...@gmail.com on 24 Nov 2012 at 11:05

[GoogleCodeExporter]

Rispondo prima ad elisa:
>>>? per fare i mockup avrei bisogno di sapere in che modo si vuole 
rappresentare la visualizzazione delle notifiche?
Crea una issue e metti nei cc Alfonso Murolo, Alfonso Piscietelli, Giulio 
Franco e Angelo Scafuro

>>>? non ci sono da aggiungere anche sequenca diagram e statechart diagram. 
giusto?
Se fai un unico sequence non sarebbe male

>>>inserimento entità notifica all'interno del diagramma ER?
Si almeno inseriscilo nell'ER poi c'è già una issue per le modifiche al .sql

>>>inserimento nelle tabelle descrittive delle entità?
Non sarebbe male :D

>>>modifca anche del documento schema logico?
Intendi l'ER?

>>>inserimento di gestione notifiche nei Servizi dei sottosistemi
E' stato già inserito 

>>>inserimento di gestione notifiche in component diagram, pacchetti e 
divisione sottosistemi?
E' stato già inserito

>>>modifica pacchetti e control per inserimento di notifiche
Crea una issue e aggiungi tutti quelli che si occupano di Application 
(soprattutto Antonio Cesarano)

Original comment by hilin...@gmail.com on 24 Nov 2012 at 2:49

[GoogleCodeExporter]

Rispondo a Yuri
>>>a questa fase della progettazione è strettamente necessario realizzare i 
nuovi mock-ups per le modifiche appena implementate?
Non sarebbe male farlo se questo non ti porta via molto tempo

>>>Risolta tutta la questione per gli UC: ho separato le tre tipologie di 
iscrizione (come già fatto nei precedenti use cases) ed ho inserito l'UC per 
il completamento delle iscrizione (dubbio: deve includere le precedenti 
tipologie di iscrizione? in questo caso, serve un generico per le tre 
iscrizioni?).
Ho inserito poi l'UC per visualizzare le iscrizioni non convalidate e quello 
per convalidare le iscrizioni.
Provvedo ad effettuare le altre modifiche nel RAD.

Prima di tutto hai fatto gli UCD? Se non li hai fatti questi ti possono aiutare 
a capire meglio.

>>>dubbio: deve includere le precedenti tipologie di iscrizione? in questo 
caso, serve un generico per le tre iscrizioni?
Dovrebbe essere semplicemente una precodizione dell'iscrizione se vuoi 
generalizzare e ti trovi meglio fai pure ;)

Original comment by hilin...@gmail.com on 24 Nov 2012 at 2:54

[GoogleCodeExporter]

A seguito di questi cambiamenti riguardate gli scenari 

Original comment by hilin...@gmail.com on 24 Nov 2012 at 2:55

[GoogleCodeExporter]

Comunque ho capito che intendi per doppia iscrizione :D vediamo bene di non 
chiamarla cosi davanti alla prof ^_^

Original comment by hilin...@gmail.com on 24 Nov 2012 at 3:00

[GoogleCodeExporter]

>>>Prima di tutto hai fatto gli UCD? Se non li hai fatti questi ti possono 
aiutare a capire meglio.
>>>Dovrebbe essere semplicemente una precodizione dell'iscrizione se vuoi 
generalizzare e ti trovi meglio fai pure ;)

Sì, gli UCD li ho fatti, e proprio per quello mi sono quasi sentito in dovere 
di generalizzare: secondo il mio ragionamento dovrei avere tre frecce di 
inclusione che collegano i tre casi all'UC di completamento iscrizione, ma 
questo vorrebbe dire includerli tutti e 3, e quindi mi sorge naturale una 
generalizzazione.
Stesso discorso per per l'inclusione nelle entry conditions: dovrei inserire 
l'OR per le tre casistiche, cosa che non è affatto piaciuta nelle fasi 
precedenti!

Original comment by yuri...@gmail.com on 24 Nov 2012 at 3:07

[GoogleCodeExporter]

Si quindi comportati come piu ti sembra giusto poi committi e ci do un occhiata 
;)

Original comment by hilin...@gmail.com on 24 Nov 2012 at 3:10

[GoogleCodeExporter]

Original comment by funfor...@gmail.com on 24 Nov 2012 at 3:38

• Now blocking: #45

[GoogleCodeExporter]

non riesco a modificare lo schema ER, non so perchè. Il resto è fatto, per un 
paio di cose attendo ancora risposte da qualcuno, appena le ho inserisco

Original comment by elisa.de...@gmail.com on 24 Nov 2012 at 8:40

[GoogleCodeExporter]

Linda, ho modificato l'UCD nel file UCD_A_3 GestioneDatiPersonaliCompleto.uxf 
(rev1610) per farti capire le mie intenzioni, se per te è ok provvedo a creare 
l'UC generico [gli specifici sono già stati creati].

Original comment by yuri...@gmail.com on 24 Nov 2012 at 9:55

[GoogleCodeExporter]

Elisa come mai non riesci a modificare l'er?

Andrea domani do un'occhiata a tutto ;)

Original comment by hilin...@gmail.com on 25 Nov 2012 at 2:29

[GoogleCodeExporter]

Girando per i files ho trovato una collisione nella r1610:

C'è una collisione negli identificativi UC da UC_A_71 a UC_A_73:
Sono UC DIVERSI sia in Gestione Personale sia in Gestione Notifiche.
Raccomanderei a Elisa di cambiare gli identificativi nella gestione notifiche 
committata oggi per evitare ambiguità.

Original comment by funfor...@gmail.com on 25 Nov 2012 at 12:58

[GoogleCodeExporter]

ho rinominato i casi d'uso UC_A_
Gestione Dati Personali\
71->76
72->77
73->78

per evitare che andassero in conflitto con quelli in Gestione Notifiche.
Spero che Andrea mi confermi che non ci sono ripercussioni per questa decisione.

Original comment by funfor...@gmail.com on 25 Nov 2012 at 4:39

[GoogleCodeExporter]

Ho anche precisato l'inclusione della visualizzazione delle notifiche che 
avviene nei casi d'uso di conferma o di rigetto di una suddivisione in classi.

Original comment by funfor...@gmail.com on 25 Nov 2012 at 4:44

[GoogleCodeExporter]

Ragazzi state riguardando gli scenari a seguito di queste modifiche?

Original comment by hilin...@gmail.com on 25 Nov 2012 at 4:44

[GoogleCodeExporter]

Alfonso, nessuna ripercussione per gli scenari.
Linda, ora do uno sguardo anche agli scenari, intanto se mi confermi le 
modifiche provvedo ad aggiornare gli UC!

Original comment by yuri...@gmail.com on 25 Nov 2012 at 6:19

[GoogleCodeExporter]

Sto aggiornando gli scenari relativi alle iscrizioni togliendo la parte 
relativa al completamento dell'iscrizione (quella da completare dopo la 
scadenza del bando), è necessario scrivere lo scenario relativo al 
completamento dell'iscrizione o basta l'UC?

Original comment by yuri...@gmail.com on 25 Nov 2012 at 6:23

[GoogleCodeExporter]

Per quanto mi riguarda puoi troncare lo scenario alla prima fase 
dell'iscrizione. 

Original comment by funfor...@gmail.com on 25 Nov 2012 at 7:24

[GoogleCodeExporter]

Andrea è rimasto allocato ancora quì, in quanto ci sono i seguenti 
cambiamenti da fare sul RAD:

-Redazione, ove possibile, dei requisiti funzionali in termini di operazioni 
(inserimento, modifica, cancellazione, visualizzazione...)
-Scorporamento dell'impiegato di segreteria in due tipi di impiegati:
1) Impiegato del diritto allo studio (colui che gestisce i bandi per l'accesso 
all'asilo, le graduatorie e quindi i relativi termini e l'assegnazione dei 
punteggi)
2) Impiegato dell'asilo (gestione del personale, delle classi e dei servizi, 
categoria tra l'altro estesa dal direttore)

Vorrei che Andrea apportasse la correzione nel RAD del team A.
Se possibile, dato che Mariella sta assistendo alla revisione trasversale dei 
documenti, vorrei che si occupasse anche di effettuare questo scorporamento 
degli impiegati per il RAD del team 2.

Sarà necessario cambiare anche i diagrammi dei casi d'uso.
Vorrei inoltre che indagaste eventuali ripercussioni sull'ER: cambia qualcosa?

Original comment by funfor...@gmail.com on 27 Nov 2012 at 1:24

[GoogleCodeExporter]

La validazione dei nostri requisiti è andata abbastanza bene oggi.
I pochi cambiamenti da aggiungere, oltre a quelli scritti nel commento 
precedente, sono:

-Nella schermata di assegnazione punteggi, è necessario aggiungere la 
possibilità di ESCLUDERE il candidato (senza attribuirgli punteggio) e 
motivare l'esclusione con una nota.

-Alcuni diagrammi mancano di tutti i casi d'uso nei rispettivi pacakge, mentre 
alcuni hanno il collegamento all'attore sbagliato (mi pare fosse nella gestione 
classi).

-Dal diagramma della gestione classi si deve togliere la visualizzazione dei 
candidati

-Sarebbe possibile scegliere un altro nome per "candidati" nei casi d'uso ?

Aggiungo io: accorpiamo la gestione delle impostazioni del bando nel package 
della gestione del bando? (aggiungendo i relativi casi d'uso al diagramma) ?

Inoltre: i flussi degli eventi dei casi d'uso A_3, A_4, A_5 NON contengono 
all'interno i campi che devono contenere relativi alla situazione reddituale e 
di residenza dei genitori che compilano la domanda (genitore vedovo, distanza 
dall'asilo..) però dal mockup risulta che c'è la possibilità di allegare la 
situazione reddituale ISEE; nel  caso d'uso di questo non c'è traccia!
La domanda originale (per personale e studenti unisa) con tutti i campi si 
trova quì: 
http://www.unisa.it/uploads/209/modulo_domanda_personale_e_studenti_dellateneo.p
df
Occorre aggiornare questi campi!

Original comment by funfor...@gmail.com on 27 Nov 2012 at 6:28

[GoogleCodeExporter]

Inoltre se li alleghiamo, come nel mockup, COME gli impiegati dell'ufficio del 
diritto allo studio possono "aprire" quei files? C'è un caso d'uso per questo 
oppure manca?
Andrea per cortesia incaricati di verificare ciò. 

Original comment by funfor...@gmail.com on 27 Nov 2012 at 6:30

[GoogleCodeExporter]

Dato anche il carico di lavoro universitario, assegno anche Antonio Barba a 
questa revisione del RAD.

Antonio, rileggi cortesemente almeno gli ultimi due commenti per capire cosa 
c'è da fare.

Original comment by funfor...@gmail.com on 27 Nov 2012 at 6:37

[GoogleCodeExporter]

L'alternativa all'allegato ISEE comunque è la specifica del valore ISEE nei 
campi da inserire.
-ISEE € xxxxx.yy

Original comment by funfor...@gmail.com on 27 Nov 2012 at 6:46

[GoogleCodeExporter]

Ok io posso farlo ma quando è la scadenza perchè stasera avevo un impegno.
Che cosa mi predo io delle cose assegnate da Alfonso, ditemelo voi cosi non 
creo conflitti.

Original comment by antoniob...@gmail.com on 27 Nov 2012 at 6:49

[GoogleCodeExporter]

Mettiamo il 29-11 ore 23.00  come scadenza per le modifiche, per ora.

Original comment by funfor...@gmail.com on 27 Nov 2012 at 6:55

[GoogleCodeExporter]

Original comment by funfor...@gmail.com on 27 Nov 2012 at 10:44

• Added labels: Scadenza-29-11-2012
• Removed labels: Scadenza-24-11-2012

[GoogleCodeExporter]

Ho creato UC_79 per l'esclusione del bambino da parte dell'impiegato asilo, e 
ho aggiornato gli UC 3 4 5 con i dati mancanti

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 3:35

[GoogleCodeExporter]

Edit: ho aggiunto anche il fatto che l'isee viene inserito mediante un valore e 
non attraverso l'up di un documento.

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 3:37

[GoogleCodeExporter]

Ricevuto. Fammi sapere appena puoi per quando riesci a correggere anche i 
diagrammi.

Original comment by funfor...@gmail.com on 28 Nov 2012 at 3:42

[GoogleCodeExporter]

Alf perdonami dammi un oretta di pausa che tengo da fare un servizio imprevisto

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 4:05

[GoogleCodeExporter]

Alfò segui questo ragionamento e dimmi se e dove sbaglio:
UC_42 Accettazione bambino
UC_43 Pubblicazione graduatoria
UC_79 Esclusione bambino
l'attore è personale asilo ma è sbagliato perchè dovrebbe essere Impiegato 
del diritto allo studio. Giusto?
Se è cosi perchè questi tre UC non li sposto da gestione dati personali a 
gestione dati bando? Cosi faccio lo UCD con un unico attore e devo modificare 
poco lo UCD 3 lasciando l'attore personale asilo.
Se tutto il ragionamento è giusto mi devi dire se il personale asilo può 
visualizzare  la lista dei candidati accettati e non e se devo cambiare 
l'attore da personale asilo a impiegato asilo negli uc di modifica classe e 
modifica certificati.

In più sempre se tutto il ragionamento è giusto devo fare uno uc pure per la 
visualizzazione della lista dei candidati da Impiegato del diritto allo studio 
o cambio solo l'attore e il nome di quelli già presenti (se impiegato 
dell'asilo non può vedere le graduatorie)

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 4:47

[GoogleCodeExporter]

Esatto, dovrebbe essere l'impiegato del diritto allo studio.
Se ti è più comodo lasciarli nell'altro package fai così. :)

Tuttavia nell'UCD 3 non puoi lasciare personale amministrazione perché alcuni 
di quei casi d'uso sono gestiti dall'impiegato del diritto allo studio (quelli 
dei punteggi e delle consultazione delle domande), altri invece dall'impiegato 
dell'asilo (certificati iscrizione, convalida iscrizione, visualizza iscrizioni 
non convalidate etc.). Devi quindi collegare i casi d'uso presenti all'attore 
giusto.

L'impiegato dell'asilo non può vedere le graduatorie e assegnargli punteggi, 
quindi cambia solo l'attore del caso d'uso già presente.
L'impiegato dell'asilo può solo trattare le "Iscrizioni all'asilo", e non le 
"domande per il bando", quindi in questo pacakge può vedere solo le iscrizioni 
non ancora convalidate e le può convalidare.

Inoltre il caso d'uso "Modifica classe" presente nel diagramma UCD 3 non 
dovrebbe esserci, perché se non sbaglio è l'assegnazione dei bambini alle 
classi, e questo avviene nell'altro package "Gestione Iscritti".

Original comment by funfor...@gmail.com on 28 Nov 2012 at 5:33

[GoogleCodeExporter]

No Alfò come l'ha detta tu non posso spostarli nell'altro package. 
Ricapitolando:
Cambio gli attori dei UC 42 43 79.
UCD 3 aggiungo il nuovo attore Impiegato del diritto allo studio e cambio il 
nome di quello presente in umpiegato asilo.
Resta l'unico dubbio, nei restanti uc lascio Personale asilo o anche li devo 
cambiare l'attore in impiegato asiso (quali visualizzazione, controllo 
certificati, ecc)

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 5:39

[GoogleCodeExporter]

Devi mettere l'impiegato giusto temo.

Original comment by funfor...@gmail.com on 28 Nov 2012 at 5:41

[GoogleCodeExporter]

Porca miseria, mi sa che ci metto un po visto che dovrei aprirli tutti, 
tecnicamente anche quelli degli altri package, giusto?

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 5:43

[GoogleCodeExporter]

il problema credo si ripercuote solo per questo package e gestione iscritti 
temo. 
Comunque varrebbe la pena di controllare anche gli altri package, ma a occhio 
direi che non sono intaccati dalla cosa.

Original comment by funfor...@gmail.com on 28 Nov 2012 at 5:45

[GoogleCodeExporter]

Il problema degli altri dovrebbe essere solo il nome dell'attore ora non 
ricordo bene ma personale asilo generico l'abbiamo usato spesso e visto che ora 
in personale asilo fa parte anche Impiegato del diritto allo studio che non ha 
tanti permessi la cosa potrebbe portare a conflitti.
Comunque Alfò ora mi metto a lavorare e alla fine di tutto preparati per altre 
domande.
Una sola cosa nel package gestione dati bando ci sono solo due UC e nessun UCD 
si deve fare quest'ultimo o sorvoliamo?

Original comment by antoniob...@gmail.com on 28 Nov 2012 at 5:50

[GoogleCodeExporter]

eh io perciò ti dicevo di unire Gestione Dati Bando e Gestione dati personali 
(che contiene le domande del bando) perchè così si univano le cose e 
mettevamo quei due casi d'uso nel diagramma :)

Original comment by funfor...@gmail.com on 28 Nov 2012 at 5:52