Newsgroup: it.lavoro.informatica
Titolo: Software's Chronic Crisis (Scientific American settembre 1994)

Quindici anni fa come oggi: una finestra sul mondo dei progetti
software falliti dopo aver consumato soldi a palate.
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
Tanto per parlare di software engineering invece che di politica e di
beni comrpati a rate.
Saluti.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 Saluti.
Andrea

wikipedia, è del 1986
Non e' che parli di concetti propriamente nuovi, ma visto che en
passant parla anche dell'allora nascente fenomeno dell'outsourcing,
dei vari approcci per garantire la qualita' del software e visto che
in 15 anni non e' cambiato una mazza se non le buzzword e le tendenze,
dovrebbe far riflettere...


 Tanto per parlare di software engineering
Adesso ti aggredisconop che è roba del passato e che ci vuole
programmazione [fr]agile. :-D

 programmazione [fr]agile. :-D
Veramente e' da almeno 11 anni che il modello "waterfall" viene considerato
"fallito", almeno a livello di ricerca universitaria (salvo ripensamenti
degli ultimi 3-4 anni su cui non sono informato)
Che poi nelle aziende le cose vadano diversamente non testimonia
particolarmente a favore dell' intelligenza delle aziende.
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 software falliti dopo aver consumato soldi a palate.
Hai usato il termine sbagliato. Non sono falliti i progetti, sono dei
falliti quei presunti guru che da 15 anni ci impestano con le loro idee.
Dietro i fallimenti ci sono sempre uomini e donne che ne sono
pienamente responsabili.



Quando spendi N milioni di dollari in software e non funziona una
cippa e alla fine stacchi la spina per disperazione e rimani col
sistema vecchio mi pare si stia parlando di fallimento di un progetto.


 particolarmente a favore dell' intelligenza delle aziende.
Per mia fortuna in molte aziede vedo che l'agile regna sovrano, ed č
grazie ai casini che combinano gli "agilisti" che a me si aprono sempre
nuove opportunita di lavoro ed č grazie a questi che io campo.
Le tue parole mi riempiono di gioia, continua con la diffusione del
verbo agile, hai tutta la mia benedizione. :-D

 questo articolo e` stato inviato via web dal servizio gratuitohttp://
www.newsland.it/newssegnala
 gli abusi ad 
ab...@newsland.it
Vabbe' io non la metterei sempre in polemica .. capisco al max quando
si parla di politica ma non di programmazione :)
Il penso che l' "ingegneria del software" sia una pura illusione.. e
sapete una cosa.. non mi scandalizza per niente.
Credo che ci sia un malinteso fondamentale che piaga l'informatica e
la programmazione, cioe' che la creazione di software possa essere
assimilata all'ingegneria civile o alla produzione industriale. Il
fatto e' che la programmazione appartiene ad un reame completamente
diverso. Si constuiscono edifici molto complessi e dai costi piu'
astronomici dei piu' costosi progetti sofware.. ma spesso questi
edifici non sono altro che versioni scalate in grande di progetti gia'
realizzati e ben conosciuti. Inolte le tipologie di edificio sono
limitate.. spesso si tratta di realizzare l'ennesima copia di un
modello gia' realizzato. Questa differenza e' ancora piu' evidente per
quando riguarda la produzione industriale, ad esempio la produzione di
automobili, che viene spesso paragonata alla creazione  di software.
La produzione industriale si basa sul creare un numero limitatissimo
di progetti e produrre velocemente un enorme numero di copie di quei
modelli. Se il compito fosse solo di creare uno o due nuove modelli di
programma all' anno e poi farne migliaia di copie le software house lo
svolgerebbero molto piu' efficacemente dell'industria automobilistica,
ma putroppo la creazione di sofware e' un processo che si presenta
diverso di volta in volta, perche' ogni volta e' chiamato a risolvere
un problema almeno leggermente diverso.
E questo senza nemmeno contare che il fatto che la tecnologia su cui
si basa l'automobile e' fondamentalmente immobile dal 1800, mentre la
tecnologia informatica si muove alla velocita' della luce. E
l'informatica non e' nemmeno matematica o scienza pura.. la matematica
si occupa dei principi generali, l'informatica spesso di risolvere
necessita' particolari. E" in parte scienza, in parte arte creativa
come la letteratura e la musica.
Proprio per questo motivo, invece di perdersi alla vana ricerca di una
metodologia che riduca la creazione del software a un mero processo
meccanico, credo che l'unica strada percorribile per chi vuole
realizzare del software funzionale in tempi ragionevoli sia investire
nella qualita' delle persone a cui viene affidato questo compito,
esattamente come si fa quando si vuole costituire in team di ricerca
con i migliori scienziati o un 'orchestra leggendaria con i migliori
musicisti.
La chiave per evitare il fallimento di un progetto software e'
affidarlo a programmatori esperti, brillanti ,creativi  e motivati. La
programmazione e' un' arte, e a meno che non sia stia sviluppando il
solito progetto da quattro soldi e' un' attivita' che va affidata a
degli artisti.

 nuove opportunita di lavoro ed č grazie a questi che io campo.
Tutte le metodologie andrebbero CAPITE, ADATTATE e quindi APPLICATE 
correttamente....
Ad esempio, il "pair programming"... quale illuminato manager di aziende 
italiane consente ai propri programmatori di programmare "in coppia" ?
Francesco

 degli artisti.
Dopo gli scambi del thread sui cv questa volta non posso che essere
pienamente d'accordo con te.
PaF

 verbo agile, hai tutta la mia benedizione. :-D
Hai perfettamente ragione, visto che, come dicevo nell'altro post
l'intelligenza delle aziende non e` tra le piu` brillanti.
E il tuo post pare una chiara dimostrazione dell' affermazione.


 beni comrpati a rate.
Anche tu sei sempre nei miei pensieri, amore.... :-PPPPPPPPPPP 
-- 
_______________________
Luc (35, CO)
Statement has no effect
_______________________

 degli artisti.
Tu hai presente la differenza che c'e' tra creativita' e innovazione ?
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


PaF ha scritto:



Il problmema e' che se siete d'accordo su questo particolare punto
significa anche che le aziende possono piu' o meno chiudere
tranquillamente tutte; 
secondo voi qualche azienda investirebbe assumendo dei pittori ? Magari
forse qualche casa editrice che produce fumetti. Oppure qualche casa
discografica potrebbe "assumere" dei musicisti. Ma quello che si intende
normalmente con "azienda" non e' esattamente questo. Per altro nessuna
di queste aziende e', di solito, particolarmente innovativa  
, pur essendo ad alto contenuto di creativita' [quando lavoravo all'
universita', alcuni miei colleghi che si occupavano di computer graphics,
mi dissero che avevano ottenuto un contratto per lavorare a qualche
"effetto cinematografico" per "non so quale" film di Carlo Rambaldi. Quello
che raccontavano erano cose turche... della serie, che avevano una specie
di "pupazzo gigante" che faceva dei movimenti in base alle note musicali
che i suoi sensori riuscivano ad percepire. Bene, per far muovere tale
"pupazzo gigante", non avevano pensato di registrare un brano musicale
e poi riprodurlo ogni volta che dovevano fargli fare gli stessi movimenti,
ma avevano un musicista che si metteva al pianoforte e ogni volta
rieseguiva lo stesso brano musicale per far muovere il suddetto pupazzo:
molto creativo, ma livello di innovazione pressoche' nullo])
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


 tranquillamente tutte; 
Al successo di un'azienda concorrono molti elementi, uno dei quali per me è
la qualità del personale.
Ci sono problemi informatici che possono essere risolti più facilmente e/o
in miglior modo se l'analista di turno e/o lo sviluppatore ha quel tocco di
genialità o artistico in più rispetto al semplice pigia tasti.
Noi (inteso come professionisti IT) non avvitiamo bulloni come in una
catena di montaggio, lavoro per il quale ci vogliono competenze ma non un
particolare estro creativo.
PaF

 E il tuo post pare una chiara dimostrazione dell' affermazione.
Piano con gli insulti. Il mio post era ironico, ma tu offendi.
Poi, non vedo dove sta il problema, io programmo a modo mio, tu a modo
tua e, come ti ho scritto, mi va benissimo che tu programmi a modo tuo.
Ce ne fossero di piů di quelli come te. io non potrei che trarre
profitto da questo.

 correttamente....
Le metodologie, già, non fuffa.

 sistema vecchio mi pare si stia parlando di fallimento di un progetto.
Sei un buonista.  I progetti qualche essere umano li propone, li
approva, li realizza. Mai visto i progetti che camminano da soli :-)
Se poi sono progetti da N milioni di dollari, sicuramente c'è
coinvolto qualche pensatore di alto livello, di quelli che vanno per
la maggiore.

 tecnologia informatica si muove alla velocita' della luce.
Non si può discutere sulla velocità del cambiamento IT, dovuto anche
alla sua giovane età. Ma anche la tecnologia meccanica/elettrica
dell'auto non è propriamente rimasta ferma, eh.... Magari proprio per
l'uso massiccio dell'IT sia nella progettazione che nella produzione.
Di diverso vedo che nell'IT si tende molto a *non* riusare parti di
software perfettamente riusabili. E questo per svariati motivi, su cui
si può aprire una discussione.

 correttamente....
Però se la metodologia è astrusa, difficilissima da capire per i
poveri "umani"...
D'altronde i fallimenti di cui si parla nel vecchio articolo non hanno
assolutamente niente a che fare con l'IT italiano, ma sono avvenuti in
paesi ben più ricettivi nelle nuove tecnologie. Ne consegue che è
proprio la metodologia ad avere dei buchi grossi come la groviera.

 Francesco
Poi il programmatore che detiene la conoscenza se ne va e sono CAVOLI
AMARI :-)


Buongiorno!!!! Finalmente uno che vede le cose dalla parte dell'azienda
(ma era così difficile? Non parlo per te ma per alcuni altri.). Ma si
sa, quei le aziende sono viste solo come degli incetriolatori che
vogliono che il programmatore lavori gratis.

 profitto da questo.
Ecco. Invece questo mi sembra leggermente offensivo per chi programma
in modo che non e' il tuo (e che purtroppo non e' nemmeno il mio,
visto che nei posti dove lavoro io il modello waterfall e' sicuramente
il piu' usato e la causa dei principali casini) e per niente in
linea con quello che dici due righe sopra.


Wolferin ha scritto:


La conoscenza di cosa ?
Non mi dire che anche tu sei convinto che uno possa fare il programmatore
senza saper leggere il codice !


 piu' tale newsgroup) 
Scrivo qui anche se forse non c'entra molto con l'OP, ma
sono andato a vedere  il newsgroup comp.software-eng
Mah ... ?! Gia' al primo impatto e' una tristezza... 
Poi sono andato anche a leggere questo:
http://www.newsland.it/nr/browse/comp.software-eng/26662.html
Penso che si commenti da solo...
E qui non c'e' nemmeno il messico al confine...


 senza saper leggere il codice !
Non è solo conoscenza del linguaggio di programmazione usato, ma 
dell'algoritmo, dell'eventuale presenza di shortcut, del controllo sulla 
presenza della documentazione, del "dominio di conoscenze" specifico 
dell'applicazione....
Ho avuto modo di sviluppare un programma in "pair programming" e ci 
siamo trovati benissimo e ora siamo in due a conoscere il work-flow 
dell'applicazione....

 dell'applicazione....
Appunto...
intanto se programmi "in pair", se anche uno se ne va, l'altro resta.
E se anche se ne andassero entrambi resta il codice e i file
di configurazione da cui in genere puoi ricavare tutte le conoscenze
che ti servono.
Cosa che invece difficilmente riesci a ricavare dai documenti di analisi,
sempre disallineati rispetto al codice (mai visto un progetto terminare
con codice allineato alla documentazione).


 poveri "umani"...
Beh.. si'...
Infatti piu' astruso del metodo waterfall c'e' decisamente ben poco :-)


Infatti piu' astruso del metodo waterfall c'e' decisamente ben poco :-)
A memoria il "waterfall model" (modello di Royce):
- Raccolta dei requisiti e delle specifiche
- Progettazione
- Scrittura del codice
- Integrazione
- Debugging e testing
- Installazione
- Manutenzione
Dove stanno le astrusita'?


 Penso che si commenti da solo...
Non è come si commenta ma come si intende.

 Dove stanno le astrusita'?
Mi accodo alla domanda: una verifica su
http://it.wikipedia.org/wiki/Modello_a_cascata
 mi fa pensare ad una
metodologia di sviluppo assolutamente valida, nei contesti giusti (es.
applicativi pacchettizzati sviluppati senza il fiato del cliente sul collo
degli sviluppatori).
PaF

 linea con quello che dici due righe sopra.
Dunque, quando un progetto gestito con waterfall falisce č colpa di
waterfall. E se falisce quello gestito con "medodologie" "agili"? Di chi
č la colpa? Sempre del metodo waterfall?

 beni comrpati a rate.
Non sono ancora riuscito a leggere tutto, ma
a proposito della parte che parla di produttivita'...
E' vero che ci possono essere definizioni diverse di produttivita' ma
mi e' capitato l'anno scorso di parlare proprio di questa cosa con un
economista.
Domanda (retorica) dell'economista: "se anche definiiamo banalmente
la produttivita' come input/output (ovvero: quello che si guadagna /
quello che si spende), negli ultimi 5-6 anni si e' assistito ad una
riduzione
della produttivita' o comuqnue, nella migliore delle ipotesi, un
non-aumento della produttivita', specialmente nell'area dei servizi e nelle
aziende 'innovative'. Perche' ?"
Risposta (condivisa dall'economista) : "perche' ad esempio 10 anni fa non
c'erano requisiti di tracciabilita' e di aspetti legati alla security in
genere, come ci sono oggi, ovvero gli output sono aumentati (di molto)". 
E chi lavorava 10 anni fa lo sa perfettamente. Nel 1999 se dovevi mettere
in piedi un sito web dovevi avere un ip pubblico e stop. Avendo l'ip
pubblico potevi mettere su il tuo sito.
Oggi ci sono miliardi di firewall, log di questo, log di quell'altro,
reparto "sistemisti" completamente dedicato a cose simili,
allarmistica, OSS, ecc.
Tutta questa roba *costa* e non produce alcun input aggiuntivo => va a
ridurre pesantissimamente la produttivita', piu' o meno qualsiasi
sia la definizione di produttivita'.
Osservazione finale: bisognerebbe che la definizione di produttivita',
in qualche modo tenesse conto della qualita'.
Se si pensa che un'azienda con tutti gli orpelli di cui sopra abbia
maggiore "qualita'" rispetto ad un'azienda che non li ha => allora nella
definizione della produttivita' dovrebbe in qualche modo entrare tale
qualita'. Qualcosa tipo 
produttivita'= (input economici+livello di qualita')/output
altrimenti un' azienda "sgangherata" avra' livelli di produttivita'
piu' alti rispetto ad un'azienda "di qualita'", visto che comunque
l'azienda
"di qualita'" avra' sempre output molto maggiori rispetto agli output
dell'azienda "sgangherata", che potrebbero abbassare la produttivita'
ache a fronte di maggiori input da parte dell'azienda "di qualita'". 
Ciao,
Marco


 degli sviluppatori).
Aggiungo che (a prescindere dai presunti vantaggi della programmazione
"agile" elencati qui:
http://en.wikipedia.org/wiki/Agile_software_development
già una sola cosa delle cose negative lette dalla stessa pagina a me
come azienda (che fa consulenza e che a sua volta ha bisogno di
consulenti) fa capire che un'approccio del genere (e le persone che lo
adottano) lo devo evitare come la peste:
"
    * Often used as a means to bleed money from customers through lack
of defining a deliverable
    * Lack of structure and necessary documentation
    * Only works with senior-level developers
    * Incorporates insufficient software design
    * Requires meetings at frequent intervals at enormous expense to
customers
    * Requires too much cultural change to adopt
    * Can lead to more difficult contractual negotiations
    * Can be very inefficient—if the requirements for one area of code
change through various iterations, the same programming may need to be
done several times over. Whereas if a plan were there to be followed, a
single area of code is expected to be written once.
    * Impossible to develop realistic estimates of work effort needed to
provide a quote, because at the beginning of the project no one knows
the entire scope/requirements
    * Can increase the risk of scope creep due to the lack of detailed
requirements documentation
    * Agile is feature driven, non-functional quality attributes are
hard to be placed as user stories"

Freddy Krueger ha scritto:





Nel pensare che il modello sia appunto "waterfall", ovvero nel
pensare che una volta che hai scritto i requisiti tu non debba
piu' cambiarli o nel pensare che una volta che hai fatto la parte
di progettazione, questa non la dovrai piu' cambiare, ecc.
In un progetto reale ci sono nmila linee che dalle fasi "piu' in basso"
ti fanno tornare a quelle "piu' in alto".
Ciao,
Marco
PS:
Xtreme programming (tanto per dirne una di quelle agili)
Alcune regole:
-user stories
-frequent small releases
-iteration (re-estimate some tasks, remove other tasks)
-simplicity
-refactoring
-unit test first
-agreed standards
-pair programming
-integrate often
-*collective code ownership* (per me la piu' importante)
-no overtime (per accontentare Osid :-))
-Acceptance tests are run often
Non mi sembrano piu' complicate delle fasi waterfall (anche perche'
poi queste sopra accadono praticamente sempre [tranne, purtroppo,
 gli agreed standards e la collective code ownership che invece sarebbero
fondamentali], anche quando si lavora waterfall)
Ciao,
Marco


 di progettazione, questa non la dovrai piu' cambiare, ecc.
: )
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

PaF ha scritto:



Io in oltre 10 anni di lavoro non ho ancora visto un progetto che, 
al termine, presenti un codice debuggato e testato coerente con
la raccolta dei requisiti e delle specifiche (forse qualche eccezione
per progetti di durata pari a 2 settimane ma avrei qualche dubbio.
E finche' il progetto e' da uno-due mesi, avere disallineamento puo'
non causare troppi problemi, ma quando il progetto e' teoricamente
da 3-4 anni e poi in pratica da 5-6 anni ci sono due alternative:
1) fai fallire il progetto buttando miliardi (di lire all'epoca)
2) trovi uno o piu' rincoglioniti (io uno di questi, nel caso specifico) 
che sta a lavorare dalle 8 di mattina fino a mezzanotte per sistemare il
tutto. Poi, visto che ovviamente se stai dalle 8 a mezzanotte a scrivere
codice non puoi avere il tempo di aggiornare i documenti, tu diventi
*veramente* quello che *ha la conoscenza* e che se, se ne va sono cavoli 
(anche se in realta' il codice e' li', quello che viene potrebbe avere
bisogno di molto tempo per leggerlo)


 di progettazione, questa non la dovrai piu' cambiare, ecc.
Come al solito direi che dipende:
- dal contesto
- dalla bravura degli analisti nel comprendere quello che il cliente chiede
e soprattutto NON chiede ma che potrebbe chiedere, se solo gli venisse in
mente. 
Io lavoro in tanti modi diversi a seconda dei progetti: quelli che sono
"miei" (non su commessa) sono rigidamente "waterfall": mi faccio l'analisi,
sviluppo-debuggo-rilascio, ma soprattutto se sbaglio l'analisi mi do del
pirla.
Per le commesse custom (soprattuto presso un cliente dove sono praticamente
fisso per n giorni al mese) l'analisi di solito è molto veloce, mi vengono
spiegate le nuove esigenze dai responsabili dell'area coinvolta, poi io
rielaboro il tutto con i subalterni, spesso cambiando in corsa lo sviluppo
(moltoooo agile...)
Non ritengo che un modello sia superiore in assoluto ad un altro,
semplicemente ci sono modelli che si adattano meglio di altri a seconda
delle situazioni.
PaF

Il Mon, 23 Feb 2009 14:20:51 +0100, Marcoxxx ha scritto:
[cut]
E' sufficiente pensare alla produttività cinese, n volte superiore alla 
nostra, confrontando le rispettive condizioni lavorative.
PaF

 č la colpa? Sempre del metodo waterfall?
Non so che dirti.
Io di progetti realmente falliti ne' ho visti un paio in oltre 10 anni.
Entrambi erano gestiti con metodo waterfall.
Il primo, sul quale non lavoravo direttamente, e' durato non so quanti
anni e ci lavoravano non so quante persone e quante aziende (molte,
sia persone che aziende, alcune anche multinazionali. Era un progetto che
coinvolgeva il lancio di alcuni satelliti e il software dei sistemi di
controllo). 
E non so quanti miliardi (di lire allora) abbiano perso.
Ad Un altro invece ci ho lavorato anche io, anche se li' il fallimento
non e' stato colpa del metodo waterfall (per altro *impuro*, visto
che chi doveva scrivere le specifiche non le ha mai scritte) ma e' stato
sostanzialmente un problema economico (se fai una gara "al ribasso" con
un'azienda Greca [e con aziende di altre nazionalita'] devi potergli fare
concorrenza sul prezzo basso, cosa che probabilmente nessuna multinazionale
del mondo occidentale puo' fare]
Questo per mia esperienza diretta.
So poi che esistevano studi pubblicati sulla bonta' del metodo
waterfall. Non so se ne esistano sulla bonta' dei metodi agili.
Progetti gestiti con metodo "agile" non ne' visti tantissimi negli ultimi
anni, visto che, come ti dicevo nell'altro post, dove
sono io si lavora sempre con modello waterfall, ma quando lavoravo
all'universita' sicuramente qualche progetto con metogo "agile" e' stato
seguito:
no problemi di straordinario, no problemi di malfunzionamenti (o meglio,
questi c'erano ma l'integrazione e il test continuo permettevano
di evidenziarli in fasi molto precoci dello sviluppo, quando ancora
non era un problema), molta piu' semplicita' di sviluppo, ecc.
l'unica cosa che non ho *mai* visto (e che, secondo me semplificherebbe
di molto la vita) e' la "collective code ownerswip"


 delle situazioni.
E' probabile. 
Ciao,
Marco.


fondamentali], anche quando si lavora waterfall)
Il problema e' "small releases" di cosa?


 hard to be placed as user stories"
Questa francamente non la capisco..

 incasso. E mi sta bene appunto che siano così come sono.
MMm il consulente che tutte le aziende vorrebbero avere.. e te ne
vanti pure.

 dell'applicazione....
Straquoto. Il pair programming e' un 'esperienza che tutti i
programmatori dovrebbero provare..
poi puo ' piacere o meno.. ma trovo che sia abbastanza interessante da
esser messa alla prova.

 Non e' polemica.
Lo so, non ce l 'ho affatto con te.. mi sembri un tipo ragionevole..
solo che cercavo di fare in modo che invece che in una discussione
costruttiva e di uno scambio di opinioni e di esperienze  questo
thread finisse nella solita bega italiota fra barricate diverse che si
osteggiano "a prescindere".

 particolare estro creativo.
Questo dovrebbe esser appeso sulla porta dell'ufficio di tutti i
manager. (E di qualche programmatore, temo)


Certo che me ne vanto. Quello che mi chiedono di realizzare io lo
faccio, nei migliore dei modi che so farlo. Se poi mi chiedono di
realizzare una cagata di progetto con il quale pensano di fare miliardi
(giù successo) io lo realizzo e mi permetto di dare SOLO i suggerimenti
sull'aspetto tecnico non sulla finalità del progetto. Le valutazioni
sullo scopo e sulla finalità di un progetto, se sia intelligente o
imbecille, non sta a me di farle, anche se, ovviamente, ho smepre le mie
opinioni. Quelo che mi chiedono io lo realizzzo e fatturo. Dici che non
dovrei?

 si può aprire una discussione.
Fammi qualche esempio di parti software perfettamente riusabili che
non vengono utilizzate.
Finche si ' parla di librerie di funzioni o classi come STL o IText
(lo cito giusto perche' l'ho utilizzato di recente) vengono
riutilizzate eccome. Ma il problema e' che constituiscono solo una
piccola, anche se preziosa, parte dell'applicazione. Il punto
fondamentale e' che se gia' c'e' un programma che fa quello che voglio
uso quello e non c'e' ragione di crearne uno nuovo. Ma se lo sto
sviluppando evidentemente si tratta di una cosa nuova.
Un 'altro punto fondamentale e '  ce la complessita' del software e'
non lineare. Costruire dieci piste di atterraggio richiede dieci volte
il tempo necessario per costuirne una, ma i tempi e la complessita'
per realizzare il software che gestisce quelle piste varia in maniera
molto diversa..

 dovrei?
Dipende che rapporti hai con il cliente. Se sei solo un semplice
sviluppatore nessuna obiezione, se sei anche un consulente "tecnologico"
allora è nelle mansioni di questa figura dare pareri professionali sui
progetti in fase di studio (studio di fattibilità).
PaF

 se sbagli.
Peccato che il mio tempo costa anche quando lavoro per progetti miei, anzi
costa di più perché si tratta di investimenti dei quali rientrerò solo a
progetto finito, mentre nel lavoro a commessa il ritorno è immediato a fine
sviluppo.
PaF

dicendo.
^^^^^^^^^^^astruso
Sto sviluppando una forma di dislessia... :/



Condordo al 100% e mi pare ovvio.
Chi si comporta diversamente e pensa solo a fatturare non e' un
consulente, e' il solito miope italiota che cerca di sbarcare il
lunario a trucchi e fregature del prossimo. Si crede furbo e non
capisce che contribuisce solo ad affondare il settore IT e la
reputazione sua e della sua professione, visto che alla fine le
magagne escono sempre fuori.


Sono "consulente tecnologico" e io quello che tu dici lo faccio. Non
rientro nel merito se uno mi chiede di realizzare un progetto che io
ritengo stupido per finalità che si è messo in testa il cliente. Se lui
mi chiede, per esempio, di realizzargli un clone di Excel di sicuro non
mi metto a dirgli "ma che sei scemo? A chi lo vuoi poi vendere per
rientrare con i costi (e per guadagnare)?" Io propongo le soluzioni
tecniche e se lui mi chiede di realizzare un progetto destinato al
fallimento io lo faccio senza problemi. Tanto finche paga.


Aggiungo: Glielo dico che sta facendo una cazzata, ma non mi metto a
convincerlo.- Cazzi suoi. Del resto non sono un commerciale e la mia non
può che essere una opinione. Se lui ha visione più ampia della mia e ha
fatto i suoi conti (bene o male che li abbia fatto) non mi riguarda.
Quello che mi chiede io gli realizzo. Punto.

 Quello che mi chiede io gli realizzo. Punto.
Scusa ma hai dato due risposte antitetiche in successione. "Non
rientri nel merito" o "glielo dici che sta facendo una cazzata" ?
Se il mio ruolo è di fare il consulente tecnologico ho il diritto/dovere di
dire al cliente se per la mia esperienza sta chiedendomi di fare una
boiata, vengo pagato per questo, anche a costo di avere una commessa in
meno da sviluppare, se convinco il cliente a desistere. 
Potrebbe sembrare stupido ma il realtà in questo modo dimostri una
correttezza ed una trasparenza totale, che per rapporti professionali
consolidati ti porta ad avere n commesse nuove per una bocciata.
Poi sia chiaro che se il cliente insiste ad oltranza e mi spiega i motivi
delle sue decisioni anch'io mi adeguo, ma in caso di insuccesso posso
sempre dire "te l'avevo detto".
Ad oggi non mi è mai successo di arrivare a sviluppare progetti che non
condividevo (il 2009 è il mio decimo anno di attività in questa posizione),
in compenso ho acquistato la totale fiducia dei miei clienti.
PaF

 in compenso ho acquistato la totale fiducia dei miei clienti.
A me neanche, da 10 anni, ma in passatop era successo, quando tutti
pensavano che con l'ecommerce avrebbero materializzato i soldi dal
nulla. Io ho sfruttato bene quella fase e non me ne frega niente. Ho
fatto il lavoro che mi è stato chiesto ed ero pagato per questo. Punto.

 Marco.


 Infatti piu' astruso del metodo waterfall c'e' decisamente ben poco
E cosa c'è di astruso nel dire: raccogli le informazioni dagli
utenti/clienti; fai un progetto, via via più dettagliato; scrivi il
codice; fai i test; il tutto corredato da un pò di documentazione
scritta? Ovviamente calando la cosa nella realtà, dove le varie fasi si
intersecano e mischiano e si riciclano.
Queste fasi sono l'abc di qualunque attività umana, non dell'IT. 

 programmatore senza saper leggere il codice !
Codice scritto così:
a := b;
c := (a / 12) * x;
if (c > 9.5) and (y = 'N') then
.......
Auguri! :-))
Infatti tu sai benissimo che spesso il codice *è* scritto così.
Talvolta per incapacità, talvolta per i tempi ristrettissimi (quelli
che sviluppano nel cuore della notte e sono cotti), talvolta per reale
calcolo (scrivo così in modo che non mi possono cacciare).

 uso quello e non c'e' ragione di crearne uno nuovo. 
Non direi proprio. Ci sono tantissimi progetti di rifacimento,
ovviamente cercando di aggiungere cose nuove, di migliorare. Ma sempre
rifacimento è.
D'altronde le tue affermazioni fanno ben capire per quale motivo i
softwaristi tendono a non riutilizzare quello che già c'è. Tutti
artisti! :-)

 artisti! :-)
Io non saro' un artista ma un attributo fondamentale del buon
programmatore lo possiedo: la pigrizia. Quindi mi guardo bene dal re-
inventare l'acqua calda.  I "sotwaristi" non tendono affatto a un bel
nulla.. tendono a cercare di lavorare bene e hanno grande rispetto e
amore per la propria professione, passione del a tutto assente in te
che denigri il vedere la programmazione come un arte.
Se si vuol cercare i responsabili dei fallimenti di progetti non credo
si debba guardare ai programmatori innamorati della loro arte ma  a
manager e capi progetto, incompetenti in campo informatico, consulenti
alla "System Failure" (un nome, una garanzia) che pensano solo a
spremere soldi al cliente e programmatori "alla pizzaiuola", come
direbbe un mio caro amico.

 Dove stanno le astrusita'?
Le /assurdità/ (sarebbe meglio chiamarle così) stanno nel fatto che non 
ci sono anelli di controreazione tra una fase e l'altra.
I modelli BDUF funzionano soltanto in situazioni in cui le specifiche 
siano perfettamente note, fin nei minimi dettagli, fin dall'inizio del 
progetto.
Cosa che nello sviluppo software non accade mai, se non per progetti di 
dimensioni e complessità infime.
In pratica il waterfall model è il tentativo di trasporre nello sviluppo 
software le metodologie di lavoro in uso nell'edilizia, ed è per inciso 
la metodologia adottata qui da noi da agenzie di stato quali Consip e 
CNIPA, con i risultati che sono sotto gli occhi di tutti.

System Failure wrote:
 > Marcoxxx wrote:
 >
 >>>> Tanto per parlare di software engineering
 >>> Adesso ti aggredisconop che è roba del passato e che ci vuole
 >>> programmazione [fr]agile. :-D
 >> Veramente e' da almeno 11 anni che il modello "waterfall" viene 
considerato
 >> "fallito", almeno a livello di ricerca universitaria (salvo ripensamenti
 >> degli ultimi 3-4 anni su cui non sono informato)
 >>
 >> Che poi nelle aziende le cose vadano diversamente non testimonia
 >> particolarmente a favore dell' intelligenza delle aziende.
 >
 > Per mia fortuna in molte aziede vedo che l'agile regna sovrano, ed è
 > grazie ai casini che combinano gli "agilisti" che a me si aprono sempre
 > nuove opportunita di lavoro ed è grazie a questi che io campo.
 > Le tue parole mi riempiono di gioia, continua con la diffusione del
 > verbo agile, hai tutta la mia benedizione. :-D
La mia esperienza è diametralmente opposta: io (e parecchie altre 
persone) campo (dignitosamente) grazie ai casini combinati da quelli che 
pensano che sviluppare un software complesso sia la stessa cosa che 
costruire una villetta a due piani.





E dove sta scritto che il waterfall modello devi applicare ad un
progetto in maniera monolitica?!?
Ancora oggi insegnano che un progetto va diviso in fasi e ogni fase va
fatta nascere e crescere fino a quando non e' completa.
Nessuno poi ti vieta di suddividere la fase X in 10, 20, 50, 100
sottoprogetti se non i vincoli temporali che hai (oltre un certo
limite la cosa diventa irrealistica).
Ma sia se stai attaccando la parte di frontend, sia se stai attaccando
la parte di backend, ogni attivita' puo' essere suddivisa in attivita'
piu' piccole..
Proprio per questo durante la vita di un progetto ce' la figura del
project manager che controlla cosa c'e' da fare, chi lo sta facendo,
come lo sta facendo, quanto i ritardi dell'attivita' A impattano sulla
B e via dicendo.
E ad ogni tollgate si fanno riunioni, ci si aggiorna, si discute e via
dicendo.
Certo, se si pensa di fare 1 meeting per decidere le specifiche e 1
meeting per vedere se e' tutto a posto il fallimento e' assicurato.
Sono sicuro che esistono ambienti lavorativi dove avere un project
manager e sviluppare in piu' fasi viene visto come un costo inutile e
allora si cerca di "fare il coso" in fretta e furia partendo
dall'inizio e arrivando alla fine, ma vuol dire anche che in quegli
ambienti il tasso di fallimenti sara' altissimo.
Saluti.


 costruire una villetta a due piani.
Ottimo, poi dicono che manca lavoro, e qui tutti campiamo bene.

 ambienti il tasso di fallimenti sara' altissimo.
Ma il brutto degli approcci BDUF è che sono proprio quelli che risultano 
più lenti e più costosi.
L'attività di redazione delle specifiche di dettaglio è una cosa 
estenuante, proprio perché alla fine verranno scolpite nella pietra e 
mai più toccate (nell'illusione che un /team di codifica/, senza avere 
alcun contatto con gli analisti, possa sempre e comunque implementarle 
alla lettera).
Per quello che è la mia esperienza personale, l'approccio waterfall è 
infatti adottato principalmente da aziende ed organizzazioni di 
dimensioni rilevanti ed iperburocratizzate, nelle quali il rispetto di 
(vuoti) aspetti formali e burocratici è largamente prevalente 
sull'esigenza e sulla volontà di sviluppare prodotti realmente 
funzionanti (esempio tipico, la PA italiana).

ispas wrote:

Saper scrivere codice autodocumentante, leggibile, modulare, 
parametrico, ben commentato, anziché semplicemente funzionante, è 
esattamente la differenza che passa tra un buon programmatore ed un 
cacciavitaro improvvisato.

 è la colpa? Sempre del metodo waterfall?
Diciamo che a parità di progetto, di risorse e di personale, è molto più 
probabile che il progetto medesimo fallisca se lo si gestisce con 
l'approccio waterfall piuttosto che con quello agile.

 intersecano e mischiano e si riciclano.
Il fatto che le varie fasi si intersechino si mischino e si riciclino, 
per usare i tuoi stessi termini, è esplicitamente *proibito* dalla 
metodologia waterfall.
E questo è per l'appunto, astruso.

System Failure wrote:

Ed anche le prospettive future sono brillanti, almeno fin tanto che 
l'università italiana continuerà a sfornare certi /informatici/ come 
quelli apparsi qui in recentissimi thread (che poi andranno a fare i 
dirigenti in aziende private o nella PA).
Peccato per il resto dei contribuenti italiani.

CUT
Questo e' quello che in segnano oggi all'universita': waterfall
applicato a progetti divisi in fasi e coordinati da un PM.
Ad intervalli regolari si fanno meeting e si controlla lo stato
dell'arte, se ci sono problemi causati dalle specifiche si rivedono le
specifiche e si reitera.
Flessibilita' la chiamano. :)


 calcolo (scrivo così in modo che non mi possono cacciare).
a volte (purtroppo) il codice è scritto così proprio perchè il 
'programmatore' non sa fare di meglio :-(
Andrea

 Saluti.
Andrea

 Flessibilita' la chiamano. :)
Qualcuno la chiama anche /metodologia agile/ ;-)

 knows the entire scope/requirements
francamente, non credo che questo sia legato a una metodologia piuttosto che 
a un altra :-(
Andrea

 Sto sviluppando una forma di dislessia... :/
:-)
Andrea

 manager e capi progetto, incompetenti in campo informatico,
Lanciato nella tua invettiva contro l'italica stirpe, dimentichi che
l'articolo da cui parte la discussione si riferisce solo a fallimenti
di progetti non italiani.

 di progetti non italiani.
Nelle righe che hai citato non vedo nessuna parola che inizi con ita..
si vede che hai la coda di paglia :)
In ogni caso te lo posso sottroscrivere senza problemi. L
'inconpetenza, la boria , la confusione mentale, la disorganizzazione,
la disonesta', lo sfruttamento del prossimo sono virtu' planetarie, ma
l'italiotica stirpe puo' essere fiera di essere leader del
settore...grazie anche a testimonial come te :)

 cacciavitaro improvvisato.
Sono d'accordo in linea di principio. Ma il software autodocumentante,
senza nient'altro, è un'utopia.
Oltretutto è soggettivo:  per un esperto di una certa cosa, un certo
passo di programma è come "Hello, world", mai lo commenterà perchè
semplicemente non gli viene in mente che sia necessario. Ma per un
altro può essere di difficile comprensione.

 dalla metodologia waterfall.
Non credo che vieti (e come potrebbe) di aggregare N progetti atomici e
monolitici in uno più grande, non monolitico.

ispas wrote:

Quello che vieta te l'ho scritto sopra (e l'hai pure quotato).

 altro puň essere di difficile comprensione.
Anche per questo č stata inventata una cosa che si chiama /pair 
programming/:
http://en.wikipedia.org/wiki/Pair_programming