martedì 4 dicembre 2007

Obbiettivi

In una soluzione, è necessario individuare gli obbiettivi, così com'e' fondamentale condividerli con chi si sta affrontando la soluzione.

Molte volte ci è capitato di affrontare delle suluzioni senza conoscere espressamente l'obbiettivo finale, e questo è un grosso problema, che crea pesanti conseguenze.

Immaginate la seguente richiesta... "ci serve un prodotto che faccia delle somme".
L'obbiettivo sembra chiaro, fare delle somme ma è davvero questo quello che l'utente finale vuole? e soprattutto è possibile condividere questo obbiettivo con altri?

Se lavorassimo in un Team, che cosa potremmo realizzare ? In questa richiesta mancano naturalmente tutto.

Che cosa deve sommare, (model)
come deve presentare le somme, (view)
come deve effettuare le somme (controller).

Approfondire gli obbiettivi è fondamentale, per la creazione del nostro modello. Naturalmente è d'obbligo ricondursi, al predicato MVC.

Lo scopo non è quello di perdere tempo, anzi è quello di guadagnarne finalizzando le nostre attività.

Se avessimo affrontato la richiesta, senza approfondire la reale esigenza, non avremmo potuto realizzare nulla.

Si noti questa richiesta... " da un pannello di immissione che presenta due campi editabili, che accettano solo valori numerici, l'utente premendo il tasto somma, ottiene un popup contenete il risulato della somma dei due valori immessi".

Certo si tratta di una richiesta più articolata e maggiormente definita.
C'è una definizione dei dati
c'e' una definizione della presentazione,
c'e' in fine una definizione della logica da applicare ai dati.

E' chiaro quindi che in fase di analasi non si può lasciare spazio alla superficialità, e che si debbano sempre approfondire le richieste iniziali.

Chiaramente c'e' sempre da stabilire un protocolo con il richiedente in modo che quanto richiesto persista fino al momento del rilascio.

"Va da se" che un obbiettivo può mutare nel corso del tempo, ma questa mutazione, deve essere sempre condivisa.
Se all'istante T0 la richiesta è una Bicicletta,
e all'istante T1 la richiesta è uno Scooter,
e' necessario che il Richiedente faccia circolare questa nuova necessità, in modo che chi sta producendo la
bicicletta, possa operare per apportare le modifiche, o ripartire con il progetto.

E' per questa tipologia di problemi che è necessario affrontare un lungo processo di analisi prima di partire con la progettazione.

Finalizzare, e conoscere gli obbiettivi, vi evita di montare tutti pezzi di uno scooter su una bmx ... sempre che questo
sia possibile...

Se si parla di costi in termini di tempo, immaginate la situazione appena descritta, si comprende con molta semplicità che lavorare ad un progetto non finalizzato, ci può costringere ad eseguire del lavoro doppio.

Al contrario uno sforzo iniziale considerevole nell'analisi, e nell'individuazione degli obbiettivi ci porterà alla soluzione, con un minor (si spera nessuno) numero di problemi.


Nessun commento: