[Internet-cafe-developer] PROJECT GUIDE LINES (4 ITALIANS ONLY)

[Guido A. I. <jun...@gm...>]

THIS MESSAGE IS ONLY FOR ITALIANS PROJECTS'MEMBERS (SUBPROJECT 2 AND =20
SUBPROJECT 7) DON'T CARE AT THIS MESSAGE BECAUSE ARE GUIDE LINES ON =20
HOW A SOFTWARE REQUIREMENTS ANALYSIS SHOULD BE DONE TO AVOID FUTURE =20
PROBLEMS.

Alcuni suggerimenti per il progetto di ingegneria del software:

Definiti i requisiti tramite il documento dei requisiti che vi ho =20
pseudo firmato tutto procede come vi descrivo in seguito (questa fase =20=

comprende pi=F9 iterazioni e non =E8 detto che possa cambiare anche =20
durante la fase di analisi o di progetto.. pensate a funzionalit=E0 =20
necessarie ma non prese in considerazione...):

1.0 Si definisce una visione applicativa che in poche parole dice: =20
Perch=E8 devo affrontare questo progetto (DEVO PASSARE L'ESAME, VOGLIO =20=

DAVVERO LAVORARCI, VORREI DEI PROFITTI)? Una volta finito cosa =20
aggiunger=E0 alla comunit=E0 o alla mia software house? Perch=E8 =E8 =20
indispensabile questo progetto? Se =E8 un sottoprogetto che ruolo avr=E0?

2.0 Si inizia l'analisi dei requisiti dove l'analista software prende =20=

in considerazione i problemi riscontrati nel documento dei requisiti =20
e NON si pone il problema di come risolvere i problemi riscontrati ma =20=

fornisce linee guida per la fase di analisi vera e propria. In =20
pratica in questa fase si descrivono i goal applicativi, si =20
distinguono requisiti funzionali (es. il cliente pu=F2 fare degli =20
ordini, l'amministratore pu=F2 emettere ordini verso i fornitori, lo =20
far=E0 via e-mail? per telefono? quale il ruolo del sistema in tutto =20
ci=F2 ?) e non funzionali (es. la piattaforma di sviluppo sar=E0 =
Eclipse, =20
JAVA, perch=E8? Multi piattaforma ? Il cliente richiede un integrazione =20=

o sta partendo da zero? Posso scegliere io cosa utilizzare? Posso =20
utilizzare componenti software di terze parti o sono legato a =20
qualcosa come una licenza GPL che mi pone dei limiti =20
nell'utilizzazione di software proprietario? ).

2.1 Anche detta analisi del dominio... Dove ci andremo a collocare? =20
in che contesto? cosa =E8 gi=E0 stato fatto o cosa no ? Stiamo partendo =20=

da zero?

2.2 Si descrive dettagliatamente ogni  requisito individuato ad =20
esempio: se si ha un sistema di messaggistica interna tra sistema di =20
gestione centrale e sistema di gestione al bar? come si integrano? =20
Quali sono i protocolli utilizzabili (li definiamo noi? come? )? Se =20
il database (ammesso che ci sia un database) si trova su una macchina =20=

diversa dalla nostra come accedervi? Se =E8 un sottoprogetto c'=E8 =20
qualcosa che =E8 gi=E0 stato fatto? I prodotti dove li memorizzeremo =20
servir=E0 un componente esterno? SI DESCRIVONO CMQ TUTTI I REQUISITI =20
DETTAGLIATAMENTE un paragrafo per ogni sotto requisito... (NON SIAMO =20
ANCORA IN GRADO DI CREARE DIAGRAMMI UML se non concettuali, possono =20
essere figure create con l'applicazione X .. NON SAPPIAMO ANCORA =20
NULLA... )

2.3 Dai documenti prodotti fin ora si crea il famoso GLOSSARIO (che =20
contiene solo termini, non verbi, non azioni, termini descrizioni e =20
sinonimi (si sceglie in questo caso se l'amministratore debba essere =20
chiamato gestore oppure administrator oppure altro!!! ) ).

2.4 Interazione con il cliente! Mi fate leggere tutto quello che =20
avete creato io vi dico se abbiamo dimenticato qualcosa.

2.5 Ora ci dedichiamo alla ricerca della componentistica utilizzabile =20=

e definiamo i contesti applicativi... C'=E8 un contesto di networking? =20=

Si lavora solo localmente? CHE COSA CI SERVE? descrizione sempre con =20
figure e testo...

2.6 Ora finalmente ne sappiamo abbastanza sul dominio applicativo, =20
potremmo buttare giu i fatidici diagrammi dei casi d'uso (li =20
mostriamo al cliente IO che cmq non ne dovrei sapere nulla) poi per =20
le azioni presenti nei casi d'uso e individuate fin ora dai documenti =20=

precedentemente prodotti definiamo per ogni caso d'uso (meglio =20
manatenere i casi d'uso piccoli e snelli e non farli esplodere in =20
enormi diagrammi) gli scenari! ES.: prima di poter iniziare a gestire =20=

l'inventario o effettuare ordini ai fornitori sar=E0 meglio che =20
l'amministratore si sia autenticato no ? gli scenari dovrebbero =20
essere completi di attori (sia utenti che il sistema sono attori), =20
descrizione (a che caso d'uso si riferisce ? cosa fa sto benedetto =20
scenario?) quali le precondizioni, quali le postcondizioni, qual =E8 il =20=

flusso principale, ci sono flussi alternativi per raggiungere lo =20
stesso risultato? (es. se siamo in una procedura guidata l'utente pu=F2 =20=

annullarla? ).

- Le associazioni senza freccia si usano tra gli ovali dei casi =20
d'uso, gli attori sono legati agli ovali con frecce (si intende che =20
serva l'intervento di un attore per fare qualcosa... )
- Le extend dovrebbero essere usate per arricchire un caso d'uso non =20
per funzioni core.
- Solitamente gli archi include vengono utilizzati di + ad esempio se =20=

si vuole evidenziare che nella fare di ordinazione si voglia anche =20
definire una quantit=E0 di prodotto...
- Si usano moltissimo relazioni di dipendenza ad esempio un =20
amministratore pu=F2 iniziare a gestirel'inventario se e solo se ha =20
fornito le proprie credenziali e si =E8 autenticato nel sesitema.
- Spesso si usano generalizzazioni tra gli attori es.: =20
l'amministratore pu=F2 fare le veci di un'addetto al bar mentre =20
l'addetto al bar no, quindi amministatore generalizza l'addetto al =20
bar, oppure no ? come =E8 realizzata la categorizzazione delle utenze =20=

in internet-cafe? (per ora esistono solo utenti e amministratori, si =20
deve cambiare qualcosa o pu=F2 funzionare lo stesso anche cos=EC? quale =20=

l'impatto (questo me lo descrivete nei documenti precedenti... ) ).

3.0 Fase di analisi che vi descriver=F2 quando avrete finito sti punti =20=

che vi ho elencato! Solo in questo momento possiamo considerare =20
l'oppurtunit=E0 di definire per bene gli attributi delle entit=E0, il =20=

modello applicativo e l'architettura (PCE, preferibilmente).

RICORDATE CHE PIU' DOCUMENTAZIONE PRODUCETE MEGLIO E' SIA PER VOI CHE =20=

PER IL VOSTRO CLIENTE... LA DOCUMENTAZIONE VI GUIDERA' NELLE FASI =20
SUCCESSIVE EVITANDO INCOMPRENSIONI, EVITANTO DEI "BOH" SU COME =20
RISOLVERE UN PROBLEMA, EVITANDO COSE DEL TIPO: QUESTO NON ERA STATO =20
PRESO IN CONSIDERAZIONE! ELIMINERA' ITERAZIONI SULLE FASI PRECEDENTI =20
E QUINDI PERDITE DI TEMPO!

BUON LAVORO, GOOD LUCK!
Guido

P.S: EVERYTHING SHOULD BE WROTE IN ENGLISH BUT ITS NOT A PROBLEM WE =20
HAVE OUR PROJECT TRANSLATORS.... I DIAGRAMMI DEVONO ESSERE REALIZZATI =20=

TASSATIVAMENTE IN INGLESE.. QUESTO PERCHE' I TRADUTTORI DI USE CASE, =20
DIAGRAMMI E COMPONENTI NON NE SANNO NULLA, LORO TRADUCONO, VOI =20
ANALIZZATE E PROGETTATE, VOI PRODUCETE (SPERIAMO) LORO SI LIMITANO A =20
TRADURRE...