Newsgroup: it.comp.programmare
Titolo: pianificazione del programma?

Ciao a tutti,vorrei sapere,per cortesia,e a titolo informativo,qual'è
il modo di priogrammare normalmente utilizzato ora dai
professionisti...cioè si programma già dall'inizio al terminale,oppure
si stende prima uno achema ,un diagramma,qualcosa....e se sì,fino a
che punto è preciso questo diagramma?
Si definiscono le variabili oppure le si digita direttamente al pc man
mano che vengono in mente?...
Insomma,ho letto un testo vecchiotto secondo cui ,prima di mettersi al
terminale,si dovrebbe fare una accurata progettazione del programma su
carta....vorrei sapere se questo modo di lavorare è ancora
utilizzato...

C'e' un'apposita branca dell'informatica che si chiama "Ingegneria del
Software".
Comunque per scrivere un programma che stampa sullo schermo "Ciao, mi
chiamo Pippo", non e' necessaria ... ;)
 Raffaello


 utilizzato...
La maggior parte dei testi che troverai ti mostreranno come (a parere
dell'autore) si DOVREBBE fare.  Una rara e benvenuta eccezione la
trovi nei lavori di Highsmith (in buona parte) e Alistair Cockburn
(ancora di piu`).  Cockburn in particolare e` praticamente un
*antropologo* dello sviluppo software, interessato soprattutto a
COSA effettivamente facciano le squadre di sviluppo, e quali delle
varie cose che fanno funzionano piu` o meno bene a vari scopi.  Con
autoanalisi piu` acuta della media, si autodenuncia perche` anche
le metodologie che ha pubblicato lui stesso non sono DEL TUTTO esenti
da "abbellimenti": il grosso (nel suo caso) corrisponde a quello che
EFFETTIVAMENTE si e` fatto e ha funzionato, ma e` una tentazione quasi
irresistible quella di aggiungere cose che in realta` nel progetto NON
si sono fatte, ma, ci dice una vocina interiore, si SAREBBE DOVUTO
fare, sarebbe stato BELLO E GIUSTO fare... in pratica, delle prassi
NON temprate nella fornace dell'esperienza.  Se di questo errore si
macchia persino Coburn, figurati il 99.6% degli autori!
Coburn insegna anche come condurre un'intervista per scoprire quale
EFFETTIVO insieme di metodi abbia usato o stia usando una data
squadra di programmazione -- non corrisponde quasi mai a quello che
ti dicono -- non per cattiveria, perche` "sanno" [dai libri...] che
si DOVREBBE fare x, y, z, t, in pratica y lo saltano e t lo dimezzano
perche` dall'esperienza sanno che non servono a nulla o magari sono
dannosi, ma si sentono un po' in colpa quindi, intervistati per un
libro o articolo sulle metodologie, sai...  Coburn mostra come
demolire (cortesemente ma spietatamente) questi falsi ideologici
e scoprire la realta`.  Non spiega come spiegare ai membri di una
squadra di programmazione che FUNZIONA che non hanno proprio nulla
da rimproverarsi -- se la squadra funziona, sono sballati i libri,
non i metodi usati dalla squadra.  La prova del budino sta nel
mangiarlo, non in quel che c'e` scritto nel libro di ricette...
In pratica, le procedure usate, e le procedure effettivamente in
grado di funzionare, dipendono anzitutto da fattori umani: quanto
e` grande il progetto, chi c'e` nella squadra, e` un gruppo solo
o quattro sparsi per il mondo con grandi difficolta` nel comunicare
tra loro, quali sono i rapporti col cliente, e cosi` via.
Un progetto di quattro persone, tutte in una stanza, per due
settimana, richiede pochissima formalita`, soprattutto se le
persone sono esperte (puo` bastare che lo siano, diciamo, due
su quattro, se gli altri sono disposti a sudar sangue per
imparare in fretta e sul campo: se uno invece che un vero
pragmatico e` un ideologo convinto che tutto quello che gli
hanno appena insegnato all'universita` sia vangelo, invece,
possono esser mal di panza notevoli).  Un progetto con duecento
programmatori divisi in dieci squadre in diversi fusi orari,
la meta` delle persone neolaureati o peggio, e un paio d'anni
di durata, e` un grande mal di testa comunque lo si gestisca,
ma comunque e` di certo necessaria MOLTA piu` carta (e in
generale formalita` e cerimonia) rispetto al caso precedente.
Highsmith suggerisce (tenendo in considerazione la natura
umana...) di pianificare di avere *appena MENO organizzazione
del minimo indispensabile*.  Non MOLTA meno, ma APPENA meno.
Ma Highsmith e` fra gli alti sacerdoti delle metodologie
Agili; da quelli delle Rigorose sentirai un'altra campana!
C'e` anche un libro (costoso ma bello) dedicato al
"metodo personale di programmazione" che definisce strutture
rigorose che dovrebbe usare anche UNA singola persona nello
sviluppo di un progettino... decisamente non congruente com
"appena meno del minimo indispensabile"!-).  Comunque
Highsmith non parla ai principianti, e tutto sommato neppure
Coburn.  E` ragionevole pensare che mancando di essperienza
e di cultura sia bene supplirvi con una dose un poco piu`
abbondante di formalismo e segui-la-ricetta, rispetto a quella
che si applicherebbe a professionisti piu` esperti.
Alex

 [....cut...]
E' sempre un piacere leggere i tuoi post anche se nel mentre i minuti
scorrono veloci :-)
--
Rhymes
rhy...@myself.com
" ride or die "

 fammi indovinare y è il debugging e t il testing ;-) ?
No per carita`, parliamo di programmi RIUSCITI, e quelli il testing
non lo lesinano MAI: e` la singola tecnica piu` importante di tutto
lo sviluppo, in tutte le sue salse.  No, quelli saltati di solito
sono i diecimila dannati diagrammi previsti dalle varie metodologie
(a mio parere soprattutto allo scopo di fornire belle illustrazioni
per libri e articoli:-).
Alex

per libri e articoli:-).
:)
ciao!


 Eh eh il Nutshell ti aspetta :)
Esatto... *sigh*.
Mo' stacco i newsgroup... e ci si risente ad Agosto o Settembre... per
qualsiasi comunicazione urgente, resto disponibile in mail.
Buona estate, e pochi bug a tutti.
Alex

Esatto... *sigh*.
Buona fortuna per i due libri !



Martino.

On Tue, 09 Jul 2002 14:34:40 GMT, 
mazz...@libero.it
 (Alberto) wrote:
Grazie a tutti ....non mi aspettavo delle risposte così
articolate,infatti devo ancòra finire di leggerle :-)
Visto che siete disponibili,casomai vi chiederò qualche altra
delucidazione :-)
Ciao,
Alberto.

 assolutamente nulla! ;)
I clienti non sono stupidi: almeno, non lo sono i miei.  Trattarli
da stupidi, o pensare che lo siano, sarebbe un gravissimo errore.
Forse e` anche questione di sapere comunicare con chiarezza ed
efficacia.  Chi e` incapace di comunicare difficilmente avra`
grande successo nell'analisi dei requisiti del cliente, qualsiasi
approccio adotti.  Se non riesce neppure a comunicare cosa sia
un prototipo, e perche` un prototipo non e` un prodotto finito,
come potrebbe mai fare a comunicare cosa esattamente si propone
di fare a fronte delle cifre che richiede al cliente ... ?
Alex

un prototipo, e perche` un prototipo non e` un prodotto finito, [...]
Una volta ho portato ad un amico un prototipo di programma che gli
serviva che a parte la stampa e la tool bar era funzionante, il
dialogo è stato:
io:
|Questo è il programma, mancano ancora un paio di cose ma così puoi 
|vedere se ti piace e se fa quello che vuoi.
l'altro:
|Me se non è finito cosa me ne faccio, finiscilo e poi lo provo.
io:
|Ma così non faccio lavoro inutile per poi rifare tutto perché non ti 
|piace.
l'altro:
|Ma quanto tempo vuoi che serva per scrivere un programma del genere? 
|In dieci minuti lo fai, anzi potresti finirlo qui.
io:
|Ma qua non ho i programmi adatti per scrivere un programma.
l'altro:
|Ma guarda che Word è installato, non si usa quello?
Dopo questo discorso mi sono stufato e il programma è restato sempre a
quel punto...
-- 
Marco Barisione (ICQ 84277092)

 di fare a fronte delle cifre che richiede al cliente ... ?
Io infatti mi occupo dello sviluppo degli applicativi in base a quello che
mi viene detto (ed ho anche imparato a mie spese a non fare domande o
suggerire altre possibili interpretazione del *ClientePensiero*), non di
interfacciare il cliente.
Il mio era uno sfogo, perché, diciamolo chiaro, in Italia, chi usa i
computer in aziende non informatiche, quasi non sa come si accendono.
Probabilmente tu sei piů fortunato di me nel trovare persone in grado di
esprimere (in italiano - almeno avessi questo!) le loro problematiche e i
loro obiettivi.
E' comunque non improbabile che non si stia facendo il possibile per capire
il cliente. Accetto ben volentieri la tua critica.
Martino.

 loro obiettivi.
Devo ammettere che in questo periodo lavoro piu` che altro per
svedesi, quindi per "esprimere in italiano" non si va molto bene:-).
Ma in generale, e del tutto a parte le differenze fra un capo
e l'altro d'Europa, secondo me capirsi col cliente e` un affare
_interattivo_.  Non si tratta solo di starlo ad ascoltare (che
pure e` la cosa piu` importante: pochi SANNO ascoltare...!), ma
di interagire con lui spiegando i possibili costi di vari approcci
e accettare che alla fine la decisione sulla base dei dati da
noi forniti sia SUA -- e` lui che paga.
A volte, bisogna anche essere pronti a rimetterci: quando pare
di capire che quel di cui il cliente ha davvero bisogno e` una
spreadsheet Excel che si fa` in mezz'ora, anche se il cliente
e` disposto a pagare cento ore di lavoro per rifare, e peggio,
un'approssimazione della stessa roba, secondo me a lungo termine
conviene proporre comunque la soluzione migliore, anche se a
breve sembra di rimetterci.  E` solo cosi` che si coltiva il
RAPPORTO col cliente, che DEVE anche essere un rapporto di
fiducia reciproca.
Se poi il cliente _insiste_ per sbatterti invece addosso svariate
migliaia di euro, beh, nessuno e` un santo.  Ma nella mia
esperienza, quando si tratta di soldi (e di solito e` appunto
di quelli che si tratta), i clienti sanno ascoltare eccome
(almeno, di solito).  E capiscono la differenza fra chi e`
solo li` per succhiargli il massimo al piu` presto, e chi
invece vuole costruire e coltivare un rapporto di fiducia,
di vero valore aggiunto nei propri prodotti.
Mi dicono (per fortuna non ho molta esperienza diretta in
proposito) che e` diverso se tratti con pubbliche amministrazioni:-).
Alex

 |Me se non è finito cosa me ne faccio, finiscilo e poi lo provo.
Errori di comunicazione a monte, direi.  Avresti potuto iniziare
col determinare: qual e` il MINIMO ASSOLUTO di funzionalita` con
le quali inizieresti ad usare il programma, l'insieme minimo che
ti rende preferibile usare il programma piuttosto che non usarlo.
Questo insieme minimo e` il punto di prima possibile consegna --
non di un prototipo, in questo caso, ma di un prodotto minimale.
E prima si consegna e si osserva l'effetto nell'uso reale, prima
e meglio si puo` determinare la prossima cosa da aggiungere.
Il concetto di prototipo e` diverso: non pretende di fornire
nessuna funzionalita` effettivamente utile, bensi` esclusivamente
di facilitare la comunicazione di cosa sara` indispensabile,
utile, interessante, ovvero superfluo, nel prodotto.
Alex

 proposito) che e` diverso se tratti con pubbliche amministrazioni:-).
sto finendo in questo periodo una esperienza con le pubbliche 
amministrazioni... non la auguro a nessuno :-((
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

> utilizzato...
Penso che dipenda da quanto sia complicato il programma che devi fare.