Newsgroup: it.comp.lang.visual-basic
Titolo: [SEMI-OT] Giudizi su Analisi dei requisiti e UML

Ciao,
volevo chiedervi un giudizio sulle prime fasi dello sviluppo sw.
L'ingegneria ci insegna che dopo l'analisi dei requisiti emersa
dall'incontro con il cliente occorre effettuare la fase di
ingegnerizzazione (oggi sempre più svolta con UML).
Ora, nella realtà di piccole e forse medie imprese questa fase è saltata
a piedi pari e ci si mette subito a scrivere codice (Voglio il programma
finito per ieri).
La domanda secca è:
Secondo voi vale la pena puntare i piedi e cercar di far capire a
commerciali e "non addetti" ai lavori che la parte pre-codice è più
importante della codifica, o è solo tempo perso? ;)
Daniele.
-- 
Free As In Freedom
www.fsf.org
http://blog.libero.it/LeleB/

 o è solo tempo perso? ;)
Come dicono gli ingegneri: dipende.
Per progetti medio-piccoli butta via il libro di Ingegneria del 
Software, scrivi il programma, prendi i soldi e scappa (e NON offire 
assistenza gratuita).
Per progetti più grandi può valer la pena di tentare 
un'"evangelizzazione" della controparte, magari per esempi ("se devi 
costruire una casa, parti dalla calce o dalla carta?", e simili). 
Qualche volta funziona.

 Qualche volta funziona.
Cavolo...è anche vero che se ci si deve mettere a fare gli "esorcismi"
non si finisce più! ;)
Cmq, secondo me la verità è nel mezzo: non dico di seguire tutto
l'iter..ma un minimo di analisi..perbacco!
Ciao!


 importante della codifica, o è solo tempo perso? ;)
Se per "vale la pena" intendi "si arriva a qualcosa" la risposta purtroppo è 
NO.
Sono 5 (cinque!) anni che cerco di convincere i miei colleghi di questa 
cosa, visto anche l'immensità di tempo perso nel correre dietro a problemi 
di manutenzione del codice, ma non c'è verso e io ormai ci ho rinunciato.
Anche perchè poi se la situazione si incancrenisce troppo i problemi 
diventano così tanti e occuperanno così tanto tempo che non autorizzeranno 
mai la "perdita di tempo" di ristrutturare qualcosa.
Ciao 

 mai la "perdita di tempo" di ristrutturare qualcosa.
Mmmm...mi sa che la quasi totalità delle imprese che sviluppano
applicativi medio-piccoli si trovano in questa situazione. :(
Cmq rimango dell'idea che almeno il 50-60% del tempo si debba usare per
l'analisi...se si fa il conto:
[Tempo per scovare problemi di natura logica/strutturale nel codice]
+
[Tempo perso per riscrivere intere parti che non vanno]
+
[Tempo per il debug della nuova versione]
=
[Tempo Totale di revisione]
Questo, IMHO, sarà quasi sempre maggiore del tempo che sarebbe servito
se si fosse fatta un po' più di attenzione nella fase di analisi!
Ma forse questa è un'altra storia!!
Ciao!


 se si fosse fatta un po' più di attenzione nella fase di analisi!
Non c'è mai il tempo di farlo bene. Ma c'è sempre il tempo per rifarlo.
:-)
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo
Se i tempi non chiedono la tua parte migliore, inventa altri tempi. 
(Baolian, libro II, vv. 16-17)
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Non c'è mai il tempo di farlo bene. Ma c'è sempre il tempo per rifarlo.
Non quando ti danno 4 ore per fare un lavoro, vedi che è uno schifo, ce ne 
metti 5 rifacendolo rischiando la cazziata, scopri che tutto il programma 
era basato sul codice toccato in modo che anche una reindentazione avrebbe 
provocato effetti collaterali in tutt'altra parte dell'applicazione che non 
dovrebbe nemmeno essere interessata dalla cosa...
Una volta intrecciato il codice sapientemente, sbrogliarlo diventa un 
isastro :(
Ciao