Strutturati
[ Home ] [ Up ] [ Non Strutturati ] [ Strutturati ]

Parliamo di . . . analisi di progetto.

From: SomeoneOnTheNet!!!

1-decidere assieme al cliente (o chi per lui) COSA deve fare il software;

Questo è il punto base: far scrivere i requisti al cliente ( o ancora meglio all'utente)

2-studio di fattibilita` in base all'analisi dei requisiti del punto 1;

3-decisione dei requisiti tecnici;

4-analisi dei requisiti in base ai punti 2 e 3;

5-analisi dei tempi

6-codifica;

7-test;

From: SomeoneReply!!!

Di gran lunga, il punto piu' importante e l'1, poiche' quasi sempre il Cliente ha una vaga (e distorta) idea di cosa possa fare il SW; ti suggerirei un punto 1 cosi':

1- Analizzare assieme al tuo Cliente il processo (l'attivita') che deve essere automatizzato, procedendo con la seguente tecnica: COSA HO IN INPUT, COSA ELABORO e COSA DEVO DARE IN OUTPUT; vado di esempio:

IL TUO CLIENTE: un'azienda di produzione che invia merce (e fatture) a fronte di ordini dai sui Clienti PROCESSO CHE DEVE AUTOMATIZZARE: stampare una fattura ed inviarla al Cliente (oggi la fanno a mano e la spediscono per posta) COSA HO IN INPUT? (probabilmente un ordine o una bolla di consegna, con le quantita' spedite al Cliente...chi mi da' l'ordine? e' gia' nel sistema o e' un foglio di carta?)

COSA ELABORO? (come si costruisce la fattura? quali regole fiscali/amministrative (es.iva da applicare) devo seguire?)

COSA HO IN OUTPUT? Su che formato devo stampare? (carta libera, formato spercifico..) come devo inviarla al Cliente? (fax, email. posta...) quali problemi fiscali? (e' legale una fattura in formato elettronico (email) o la legge la vuole per forza su carta?)

Da questa analisi, potrei scoprire che per fare un sistema che stampi le fatture devo prima costruire un sistema che mi faccia imputare gli ordini perche' oggi il Cliente li riceve (e li conserva) su fax.

Ovviamente questo e' un'esempio, ma vale sia per un processo semplice come l'invio di una fattura, che per un sistema complesso (che non e' altro che un insieme di processi correlati). Il mio intento era comunque di spingerti a focalizare esattamente il problema prima di pensare alla soluzione tecnica.

Tre ultime "dritte": Se il problema (processo) che stai analizzando e' molto complesso, inizia col dividerlo in sottoprocessi, e poi procedi ad analizzare ogni processo singolarmente e le relazioni tra ognuno

Durante l'analisi dei processi raccogli tutta la documentazione cartacea che attualmente il tuo Cliente usa per svolgere l'attivita' che deve automatizzare (fax, moduli pre-stampati ecc...) ed accertati che ti diano copie compilate (a volte sono piu' importanti le note a lato di un fax che il fax stesso).

Una volta che hai completato l'analisi, verifica col tuo Cliente il flusso del processo e spiegagli come vuoi automatizzarlo).

. . . and someone reply. . .

. . . a scuola esaltano tantissimo il punto 4 (io non ho esperinze di analisi per cui mi baso su quello che sento o studio).
I professori dicono che per un progetto GRANDE, l'analisi e` quella che determina la vita del software:

-se e` fatta bene il software nasce, vive e dura;
-se e` fatta male il software nasce, vive per un po' e poi muore per le elevate spese di mantenimento.

Io sono perfettamente d'accordo.
Dedicare anche molto tempo al punto 4 vuol dire quadagnarlo piu` volte negli anni.

Oltre a questo, COME si svolge un'analisi fatta BENE????