Link all'Articolo: http://www.hwupgrade.it/articoli/software/2170/ivar-jacobson-ecco-cosa-non-insegnano-ai-programmatori_index.html

Nel corso di una giornata dedicata alla programmazione organizzata da Microsoft, abbiamo avuto il piacere e l'onore di intervistare Ivar Jacobson, personalità importante all'interno del mondo degli sviluppatori di software.

Click sul link per visualizzare l'articolo.

Ecco i 10 comandamenti... (vabbhè, non li ho contati), comunque...
Grazie dottor Jacobson!!

lol è esattamente il discorso che ci fanno a lezione di processo e qualità - siamo messi meglio di quanto lui pensi (dal punto di vista universitario, in azienda è altro discorso) :p

E' dannatamente vero, inutile specializzarsi alle università, ci vuole pratica e esperienza cercando di capire il miglior approccio a un progetto.

C'è poco da fare: tra quello che fai a scuola/università e quello che ti trovi a dover fare in un ambiente lavorativo c'è una grande differenza; le università dovrebbero muoversi in questo senso e insegnare non solo a usare il linguaggio di turno ma a capire la metodologia e il background in cui verrà usato..così uno si trova già in qualche modo orientato al progetto di gruppo che poi sembra essere l'effettiva realtà lavorativa.

Però questo è veramente un grande, penso che tutti i professori universitari a cui seguo la lezione, (CdL in Informatica) verrebbero tutti ampiamente sverniciati da questo Jacobson. Per quando il ciclo di vita di un software sia una cosa molto complessa, inclusa anche la manutenzione, ci sono degli sviluppi veramente molto interessanti. Perchè esistono i tester? Chi meglio di uno sviluppatore è in grado di mettere mano a quello che ha scritto piuttosto che un altro? Semplice e geniale allo stesso tempo, tutti sviluppano codice e tutti sono tester, ma questo all'università o nelle aziende non te lo insegnano....:rolleyes:

Bè dai in 5 pagine ha disintegrato il primo mese del corso d' ingegneria del software mica male... è vero che i professori sono fissati con i compilatori LOL!!!!!
Sulla questione tester concordo...
Sul modello a cascata ok ma basta che ci dice bene cosa ha in mente perchè onestamente non mi è molto chiaro ok si parte da un qualcosa di semplice di base e poi lo si sviluppa man mano però non credo sia così semplice la questione

Perchè esistono i tester? Chi meglio di uno sviluppatore è in grado di mettere mano a quello che ha scritto piuttosto che un altro? Semplice e geniale allo stesso tempo, tutti sviluppano codice e tutti sono tester, ma questo all'università o nelle aziende non te lo insegnano....:rolleyes:ovviamente tu da programmatore fai anche il tuo debug... ma i tester possono servire perché il tuo software verrà guardato in modo diverso, verrà testato in modo diverso e spesso in modi che tu non prevedevi. Stessa cosa per chi scrive libri secondo te perché sono perlopiù gli altri che trovano gli errori che non tu che hai scritto?

Bè dai in 5 pagine ha disintegrato il primo mese del corso d' ingegneria del software mica male...
porte queste slide al tuo professore e chiedi motivazioni no?

Sul modello a cascata ok ma basta che ci dice bene cosa ha in mente perchè onestamente non mi è molto chiaro ok si parte da un qualcosa di semplice di base e poi lo si sviluppa man mano però non credo sia così semplice la questione
Dal punto di vista dello sviluppo è solo questione di pratica.
Il problema è che per farlo è necessario addestrare commerciali e clienti.
Soprattutto i primi...

In troppi slides (tra deprecati ovviamente) ho visto la situazione dei team dove ho lavorato....

Ecco quello che ha creato l'UML :D

Te possino....:sofico:

Cmq la PoliMI tutto quello che ha detto costui viene assolutamente insegnato nel corso di Ingegneria del Software :)

... ma anche in Poliba e nello stesso corso da te citato. Leggendo quello che ha detto, non ho riscontrato nulla di nuovo ... il problema sono le aziende ...

secondo me vedendo i corsi di ingegneria del sw della mia università, il dott. Jacobson sarebbe contento. Io ho studiato un modello che somiglia molto al suo (ora non vorrei dire una boiata, ma era l'Agile).

Però io son convinto che specializzarsi serva, anche perchè, con la crisi che gira, conviene poco buttarsi nel lavoro oggi IMHO: vedo alcuni compagni di studio come vanno (e sto parlando di INGEGNERI) a lavorare venendo pagati 800€ netti e sfruttati con contratti a termine

Cmq la PoliMI tutto quello che ha detto costui viene assolutamente insegnato nel corso di Ingegneria del Software :)
Magari le cose sono cambiate in soli 2 anni ma nel corso di Ingegneria del Software non ricordo di aver sentito nessuno parlare di tutti gli argomenti coperti da questo talk; alcuni dei concetti esposti vengono presi in considerazione solo con il corso di Software Engineering 2.

Ad ogni modo l'unica soluzione per trovare un buon compromesso è applicare quanto si legge e studia a progetti pratici che possono essere didattici o reali, un semplice esame su queste materie non permette allo studente di assimilare i concetti esposti.

(ora non vorrei dire una boiata, ma era l'Agile).
Sviluppo Agile => eXtreme Programming e Scrum. L'applicazione dei metodi di sviluppo agile non è sempre la pratica migliore secondo Ivar Jacobson.

Credo che grossomodo molti concetti citati da Jacobson sono ripresi pari pari in tutti i corsi di ingegneria del software.

Dico anche che a me nessuno ha assillato con i compilatori se non con la teoria che sta sotto. All'università sui progetti si lavora da solo o in piccoli gruppi affiatati, nemmeno abituano a lavorare in una coreografia di decine di gruppi... quindi questo è "problema" ambito azienda

vedo alcuni compagni di studio come vanno (e sto parlando di INGEGNERI) a lavorare venendo pagati 800€ netti e sfruttati con contratti a termine
Prima di trovare l'azienda attuale ho fatto dei colloqui in cui chiedevano senior developer che avessero almeno 5 anni di pratica e competenze da riempire un paio di fogli A0.
Nella migliore delle ipotesi offrivano 1000/1200 euro con contratto a tempo determinato. Risparmio le offerte delle ipotesi peggiori.

Bè dai in 5 pagine ha disintegrato il primo mese del corso d' ingegneria del software mica male... è vero che i professori sono fissati con i compilatori LOL!!!!!
Sulla questione tester concordo...
Sul modello a cascata ok ma basta che ci dice bene cosa ha in mente perchè onestamente non mi è molto chiaro ok si parte da un qualcosa di semplice di base e poi lo si sviluppa man mano però non credo sia così semplice la questione

Ma lol, c'è ancora qualche professore in uni che un corso di ing del sw si inchina difronte all'approccio a cascata? :eek:

Comunque le cose che ha detto sono le cose che normalmente si dicono in un corso di ing. del sw (o almeno in quello che ho seguito io alla Federico II):

- E' fondamentale capire cosa cavolo vuole il committente, eventualmente usando gli use case chiamando in causa tutti quelli che il sw lo dovranno usare ed, eventualmente, produrre un prototipo al volo per vedere se si è capito cosa bisogna sviluppare;

- E' importante essere flessibili durante il processo software (quindi niente waterfall) senza però esagerare andando a scadere nell'XP... dove arrivati ad un certo punto vedi i programmatori che a botte di refactoring escono pazzi e non riescono neanche a tenere agg. la documentazione;

- E' importante procedere per incrementi successivi per dare l'idea al cliente che si sta lavorando e per eventualmente poter apportare eventuali modifiche al sw tramite i feedback dello stesso

- E' importante la fase di testing e, se si chiamano professionisti dall'esterno a testare l'app. è la cosa migliore.

- E' importante produrre una documentazione chiara (anche per quei poveri cristi che in futuro dovranno metterci mano).


Non capisco cosa ci sia di sensazionalistico in quanto detto da Jacobson :)

il più delle cose riguarda dinamiche che si studiano in psicologia delle organizzazioni da 20 anni.

Ma lol, c'è ancora qualche professore in uni che un corso di ing del sw si inchina difronte all'approccio a cascata? :eek:

Comunque le cose che ha detto sono le cose che normalmente si dicono in un corso di ing. del sw (o almeno in quello che ho seguito io alla Federico II):

- E' fondamentale capire cosa cavolo vuole il committente, eventualmente usando gli use case chiamando in causa tutti quelli che il sw lo dovranno usare ed, eventualmente, produrre un prototipo al volo per vedere se si è capito cosa bisogna sviluppare;

Il prototipo non è altro che il sistema minimo funzionante, "lo scheletro" di cui parla Jacobson. Crescendo diventerà il prodotto finale.

- E' importante essere flessibili durante il processo software (quindi niente waterfall) senza però esagerare andando a scadere nell'XP... dove arrivati ad un certo punto vedi i programmatori che a botte di refactoring escono pazzi e non riescono neanche a tenere agg. la documentazione;

Ti consiglio di leggere Extreme programming explained: embrace change (Programmazione Estrema - Introduzione)
Scoprirai che non c'è niente di male nell'approccio XP.
Semplicemente come spiega bene Kent nel libro non è sempre applicabile.
Anzi se mancano i presupposti minimi, è meglio evitare.
Se applicato correttamente la documentazione tecnica sono i sorgenti stessi.

- E' importante procedere per incrementi successivi per dare l'idea al cliente che si sta lavorando e per eventualmente poter apportare eventuali modifiche al sw tramite i feedback dello stesso

Il cliente o chi per esso deve essere parte integrante del progetto, una risorsa attiva nel progetto.
Il concetto di lavorare per incrementi per voler far vedere al cliente che il lavoro va avanti è da commerciali... ;)
Si lavora per cicli incrementali, possibilmente con la regola del 20/80 per ridurre al minimo gli impatti dei cambiamenti, che sempre esistono, inutile sperare che le cose siano immutabili.

- E' importante la fase di testing e, se si chiamano professionisti dall'esterno a testare l'app. è la cosa migliore.

Mai sentito parlare di Unit Test?

- E' importante produrre una documentazione chiara (anche per quei poveri cristi che in futuro dovranno metterci mano).

I sorgenti ben scritti e commentati e gli unit test.
Se hai voglia di leggere a riguardo il libro di McConnell è un must.
Code Complete(Ingegneria del Codice)



Non capisco cosa ci sia di sensazionalistico in quanto detto da Jacobson :)

Nulla. Ma non tutti capiscono bene quel che dice...

direi che molte delle cose che dice si riscontrano nella metodologia AUP, nè agile(XP) e nè RUP, ma un misto delle cose migliori delle due....

voi che ne pensate dell'AUP?

Ho la netta impressione che all'Università queste cose le insegnano, ma nelle aziende non le mettono in pratica in modo smart... Io sono in UNIVR...

Poi sui compilatori, sono molto d'accordo. Non dico di togliere questi corsi, ma ridimensionarli di certo...

non c'è una metodologia il succo è questo, l'efficacia del processo dipende da quello che devi fare e il processo stesso va adattato e modificato non preso così com'è. E' indubbio come xp e scrum siano processi efficaci, ma bollare come inutile e vecchi tutti gli altri, cascata compreso, è sbagliato.
In sostanza è un "usate il cervello".

Prima di trovare l'azienda attuale ho fatto dei colloqui in cui chiedevano senior developer che avessero almeno 5 anni di pratica e competenze da riempire un paio di fogli A0.
Nella migliore delle ipotesi offrivano 1000/1200 euro con contratto a tempo determinato. Risparmio le offerte delle ipotesi peggiori.
Ma stai parlando di ingegneri o programmatori (diplomati)?
Perché le tue cifre non mi tornano

veramente tutto molto surreale.
al DISI di genova si insegna nell'ordine: ASM ( la macchina di von neumann ), C, Java, linguaggi funzionali Caml e soprattutto cosa ci sta dietro quindi la grammatica formale e poi l'implementazione di un parser e interprete.
e questo solo nei primi 2 anni di studio..
no comment, anzi: ma che cavolo di scuole ci sono all'estero ?

Da parte di un mio amico e collega:
"Quello che dice mi appare assolutamente ovvio e retorico.
Il titolo anziché "Ecco cosa non insegnano ai programmatori" dovrebbe essere "Ecco cosa dovrebbero capire i manager". Perché il problema è quando si organizza verticalmente la sviluppo del software.
Qualunque gruppo di programmatori, lasciato libero di agire, "seguirebbe" i dieci comandamenti elencati dal tizio. Bastano buon senso ed esperienza per capire l'importanza degli approcci da lui definiti "smart". Guardare come esempio l'open source.
E non perché il tizio ha inventato quell'obbrobrio di UML (che tenta di traformare i programmatori in disegnatori, inutlmente e senza riuscirci, reinventando a disegnini quello che già si scrive) ha diritto a maggior ascolto di altri."

Condivido in pieno.

Fermi fermi ho detto una caxxata perchè se corro un po' avanti con le slide del prof ecco che:
"I problemi del modello a cascata"
Seguiti dalla dottrina Jacobson EVVAIII!!!!!!!!!!
Mi stavo già fasciando la testa!!
Scusate ;)

bha nella mia piccolissima esperienza da studente gli strumenti di modellamento sono ben comodi, però vabbè la mia tesi si appoggiava pesantemente a ecore quindi sono fazioso :p

il più delle cose riguarda dinamiche che si studiano in psicologia delle organizzazioni da 20 anni.

:ave: :ave: :ave:

e quindi neanche tanto nuove.

Cose verissime...ma anke ovvie..e non sempre applicabili.

quando si lavora in un team abbastanza ampio..cè chi lavora su un modulo chi su un altro..nn cè comunicazione..e sembra quasi scontato questo. ci vorrebbe una persona che facesse da referente tecnico. Molto spesso i PM se ne sbattono del codice e non riescono a coordinare correttamente i sottoteams..ma pensano solo a dire che cavolo dobbiamo fare,le richieste del cliente,ecc ecc...
ovvio loro nn vedono nemmeno una riga di codice!!

partire poi da un progetto "skinny" cioè semplice per poi rinforzarlo piano piano...beh è quello che si cerca di fare...ma nn è sempre applicabile.

se bisogna cambiare la tecnologia o l'ambiente di un sistema preesistente..questo sembra alquanto difficile da applicare....:fagiano:

Ma stai parlando di ingegneri o programmatori (diplomati)?
Perché le tue cifre non mi tornano
Di dove sei?

A Bari, nel mio corso si studia UML.

Sapete cosa mi rende nervoso mentre ascolto le lezioni?
Sono cose "relativamente" stupide quelle della progettazione, dico stupide perchè programmare è molto più complicato dal mio punto di vista. Il nostro esame di Ingegneria prevedeva la realizzazione di un software completo, con tanto di progettazione e documentazione. Era un lavoro di gruppo, e si richiedeva come linguaggio il Java. Quest'anno i professori hanno deciso di togliere il progetto.
La motivazione è che nel corso degli anni i prof avevano avuto poche soddisfazioni, software realizzati male o scopiazzati, pochi quelli validi, tante lamentele a causa dell'elevata difficoltà dell'esame... ecc ecc.

Voi cosa ne pensate? Hanno fatto bene i professori? Abbiamo già provato a fargli cambiare idea, dovremmo insistere ancora di più?

Da parte di un mio amico e collega:
"Quello che dice mi appare assolutamente ovvio e retorico.
Il titolo anziché "Ecco cosa non insegnano ai programmatori" dovrebbe essere "Ecco cosa dovrebbero capire i manager". Perché il problema è quando si organizza verticalmente la sviluppo del software.
Qualunque gruppo di programmatori, lasciato libero di agire, "seguirebbe" i dieci comandamenti elencati dal tizio. Bastano buon senso ed esperienza per capire l'importanza degli approcci da lui definiti "smart". Guardare come esempio l'open source.
E non perché il tizio ha inventato quell'obbrobrio di UML (che tenta di traformare i programmatori in disegnatori, inutlmente e senza riuscirci, reinventando a disegnini quello che già si scrive) ha diritto a maggior ascolto di altri."

Condivido in pieno.

Concordo sulla mancanza di adeguata formazione dei manager. Il problema è che molti gestiscono lo sviluppo di un prodotto software come se fosse il risultato di una catena di montaggio. Fondamentalmente a cascata.
Diffido dei programmatori liberi. Tendono a diventare prima autonomi e poi anarchici. Diventando quindi "stupid" (altro che smart).
E poi dire che UML è un obbrobrio significa non averlo mai applicato adeguatamente: mai giocato alla lavagna in team?
Applicare UML non significa certo usare dal primo all'ultimo diagramma messo a disposizione dalla specifica.
Quando crei una interfaccia utente, ci infili tutti i controlli che trovi nella toolbox?

A Bari, nel mio corso si studia UML.

Sapete cosa mi rende nervoso mentre ascolto le lezioni?
Sono cose "relativamente" stupide quelle della progettazione, dico stupide perchè programmare è molto più complicato dal mio punto di vista. Il nostro esame di Ingegneria prevedeva la realizzazione di un software completo, con tanto di progettazione e documentazione. Era un lavoro di gruppo, e si richiedeva come linguaggio il Java. Quest'anno i professori hanno deciso di togliere il progetto.
La motivazione è che nel corso degli anni i prof avevano avuto poche soddisfazioni, software realizzati male o scopiazzati, pochi quelli validi, tante lamentele a causa dell'elevata difficoltà dell'esame... ecc ecc.

Voi cosa ne pensate? Hanno fatto bene i professori? Abbiamo già provato a fargli cambiare idea, dovremmo insistere ancora di più?

Non so se sia il caso di insistere o meno. Dipende quale è l'alternativa al progetto.
Certo è che al posto dei prof cercherei di capire se la poca "soddisfazione" dipende dagli studenti o da loro stessi.

A Bari, nel mio corso si studia UML.

Sapete cosa mi rende nervoso mentre ascolto le lezioni?
Ci sono passato tempo fa e anche io non ero troppo convinto di tutti questi corsi "fuffa". Poi ho visto come lavorano i miei colleghi in India e ho capito cosa vuol dire sviluppare software senza strutturarne prima le specifiche.

Sono cose "relativamente" stupide quelle della progettazione, dico stupide perchè programmare è molto più complicato dal mio punto di vista. Il nostro esame di Ingegneria prevedeva la realizzazione di un software completo, con tanto di progettazione e documentazione. Era un lavoro di gruppo, e si richiedeva come linguaggio il Java. Quest'anno i professori hanno deciso di togliere il progetto.
La motivazione è che nel corso degli anni i prof avevano avuto poche soddisfazioni, software realizzati male o scopiazzati, pochi quelli validi, tante lamentele a causa dell'elevata difficoltà dell'esame... ecc ecc.

Voi cosa ne pensate? Hanno fatto bene i professori? Abbiamo già provato a fargli cambiare idea, dovremmo insistere ancora di più?
Se devi diventare un ingegnere informatico (immagino si questo il tuo corso no?) IMHO la programmazione non sarà il tuo mestiere: per quello basta un semplice diplomato o anche meno.

Difficile è invece interpretare le specifiche del cliente, dirigere un TEAM che programma su un progetto e saper valutare se la direzione presa dal team di sviluppo è quella corretta.

Schifare UML per capire di più di C++/Java è come dire no ad un corso scienza delle costruzioni per andare a fare pratica di come si tirano su i muri in calcestruzzo; nulla da dire su questo secondo mestiere, ma io punterei un po' più in alto.

Ci sono passato tempo fa e anche io non ero troppo convinto di tutti questi corsi "fuffa". Poi ho visto come lavorano i miei colleghi in India e ho capito cosa vuol dire sviluppare software senza strutturarne prima le specifiche.


Se devi diventare un ingegnere informatico (immagino si questo il tuo corso no?) IMHO la programmazione non sarà il tuo mestiere: per quello basta un semplice diplomato o anche meno.

Difficile è invece interpretare le specifiche del cliente, dirigere un TEAM che programma su un progetto e saper valutare se la direzione presa dal team di sviluppo è quella corretta.

Schifare UML per capire di più di C++/Java è come dire no ad un corso scienza delle costruzioni per andare a fare pratica di come si tirano su i muri in calcestruzzo; nulla da dire su questo secondo mestiere, ma io punterei un po' più in alto.

:read: :read: :read: :read: :read: :read: :read: :read: :read:

L'articolo mi lascia un pò perplesso.
Per prima cose le premesse sono assolutamente false. Io ho frequentato 3 università diverse (1 per la triennale, 1 per la specialistica e 1 per l'erasmus) e questi concetti erano sempre presenti. Se ci sono davvero dei corsi di ingegneria del software che non trattino l'argomento in modo simile... allora è scadente l'univeristà per aver assunto un professore incapace.

Per il resto concordo con le conclusioni di altri utenti prima di me. Il problema non è che non vengano insegnate, ma che non si ha la possibilità di applicarle.
Io sono ancora a cavallo tra università e lavoro quindi non faccio testo, ma ne parlo spesso con i miei ex compagni di corso che ora lavorano... non ce n'è uno solo che utilizza un modello di sviluppo diverso dal waterfall.

Ci sono passato tempo fa e anche io non ero troppo convinto di tutti questi corsi "fuffa". Poi ho visto come lavorano i miei colleghi in India e ho capito cosa vuol dire sviluppare software senza strutturarne prima le specifiche.


Se devi diventare un ingegnere informatico (immagino si questo il tuo corso no?) IMHO la programmazione non sarà il tuo mestiere: per quello basta un semplice diplomato o anche meno.

Difficile è invece interpretare le specifiche del cliente, dirigere un TEAM che programma su un progetto e saper valutare se la direzione presa dal team di sviluppo è quella corretta.

Schifare UML per capire di più di C++/Java è come dire no ad un corso scienza delle costruzioni per andare a fare pratica di come si tirano su i muri in calcestruzzo; nulla da dire su questo secondo mestiere, ma io punterei un po' più in alto.

esattamente . Un ing. informatico deve ovviamente saper programmare , ma come figura poi non è un semplice programmatore ,e infatti ha competenze ben più ampie .

Cmq anche io, che non ho avuto un gran professore di ing. del software, queste cose le ho viste bene o male tutte , ciò nonostante è un ottimo articolo e l'ho molto apprezzato.

Da me avevano posto particolare attenzione alla cosa di testare il codice a mano a mano viene fatto , proprio come dice Jacbson, utilizzando strumenti come Junit (il progetto era java e ci hanno fatto usare questo) .

Poi vabbè cose come l'importanza della modularità , dell'estensibilità già vengono introdotte con informatica 2 e la programmazione a oggetti e poi riprese in ing. del software.



P.S. per hwupgrade , non è che potreste mettere online l'intervista in lingua originale preferirei sentire direttamente Jacobson

Imho, la maggior parte (mica tutti eh) dei progettisti/programmatori non laureati creano software bacato soprattutto dal punto di vista della sicurezza (siti web in particolare).

Calandomi nella realtà e avendo a che fare con i clienti (sono anche un commerciale), quando dice:
Anche in questo caso, il consiglio è: be smart. Partire con un progetto base, molto snello, con le principali richieste. Stabilite le priorità, si deve procedere passo a passo pensando al miglior modo in cui procedere.

Forse non conosce gli italiani :asd:

un grazie al dottor jacobson e a voi di hwupgrade ;)

Imho, la maggior parte (mica tutti eh) dei progettisti/programmatori non laureati creano software bacato soprattutto dal punto di vista della sicurezza (siti web in particolare).

IMHO per ogni diplomato di quella specie posso presentartene uno laureato...:O

sarà una mia impressione, ma MS rientra in pieno nel caso unsmart descritto da Jacobson :D

sarà una mia impressione, ma MS rientra in pieno nel caso unsmart descritto da Jacobson :D

sarà una mia impressione ma NON si sentiva la mancanza di un commento così...

Il prototipo non è altro che il sistema minimo funzionante, "lo scheletro" di cui parla Jacobson. Crescendo diventerà il prodotto finale.



No, il prototipo è una cosa usa e getta. Ad es. si può sviluppare velocemente la sola intefaccia grafica, che serve, durante/alla fine della stesura del SRS, per capire se si è compreso cosa bisogna andare a fare (spesso sono gli stessi committenti a non sapere cosa cercano)


Ti consiglio di leggere Extreme programming explained: embrace change (Programmazione Estrema - Introduzione)
Scoprirai che non c'è niente di male nell'approccio XP.
Semplicemente come spiega bene Kent nel libro non è sempre applicabile.
Anzi se mancano i presupposti minimi, è meglio evitare.
Se applicato correttamente la documentazione tecnica sono i sorgenti stessi.


Il problema è che, come dice anche Jacobson, si va avanti per mode e molti applicano XP dove non possibile oppure, come succede spesso: si parte con XP, il progetto si ingrandisce a dismisura e si esce pazzi dopo :muro:


Il cliente o chi per esso deve essere parte integrante del progetto, una risorsa attiva nel progetto.
Il concetto di lavorare per incrementi per voler far vedere al cliente che il lavoro va avanti è da commerciali... ;)
Si lavora per cicli incrementali, possibilmente con la regola del 20/80 per ridurre al minimo gli impatti dei cambiamenti, che sempre esistono, inutile sperare che le cose siano immutabili.


Concordo con te che gli stakeholder (quindi non solo il cliente) deve essere parte del progetto... ma spesso se gli si da troppo spago si finisce col non avere un piano di sviluppo concreto e non si rispettano le date di consegna :)
Quello di cui parlavo è proprio lo sviluppo iterativo per incrementi, fissando delle priorità sulle feature da sviluppare nell'immediato e chiedendo feedback al cliente man mano (in modo da avere la flessibilità)



Mai sentito parlare di Unit Test?


Certo, ma dopo gli unit ed i test di integrazione è cosa buona e giusta anche far fare test a chi il programma lo deve usare ed, eventualmente, anche a persone esterne al tutto (poi dipende anche dal tipo di progetto che si sta portando avanti, quello che dico io è l'ideale... :) )


I sorgenti ben scritti e commentati e gli unit test.
Se hai voglia di leggere a riguardo il libro di McConnell è un must.
Code Complete(Ingegneria del Codice)


Quando hai grossi sistemi, i soli commenti nel codice non sono abbastanza :) , perché non ci si può mettere a leggere i sorgenti per capire cosa mette a disposizione un package o un intero applicativo ad es.


Nulla. Ma non tutti capiscono bene quel che dice...

Più che altro c'è chi predica bene (sa queste cose) e poi razzola male (non le applica) :muro:

Bisognerebbe prendere tutti i sedicenti "Project manager" e fargli una cura stile arancia meccanica a base di queste slide .

Di dove sei?
Zona Piemonte. Quelle cifre le offrono società di consulenza a neolaureati con contratto a tempo indeterminato.

Zona Piemonte. Quelle cifre le offrono società di consulenza a neolaureati con contratto a tempo indeterminato.
Io ti ho portato la mia esperienza. Niente di più.
Fortunatamente sto meglio di cosi :)

No, il prototipo è una cosa usa e getta. Ad es. si può sviluppare velocemente la sola intefaccia grafica, che serve, durante/alla fine della stesura del SRS, per capire se si è compreso cosa bisogna andare a fare (spesso sono gli stessi committenti a non sapere cosa cercano)



Il problema è che, come dice anche Jacobson, si va avanti per mode e molti applicano XP dove non possibile oppure, come succede spesso: si parte con XP, il progetto si ingrandisce a dismisura e si esce pazzi dopo :muro:



Concordo con te che gli stakeholder (quindi non solo il cliente) deve essere parte del progetto... ma spesso se gli si da troppo spago si finisce col non avere un piano di sviluppo concreto e non si rispettano le date di consegna :)
Quello di cui parlavo è proprio lo sviluppo iterativo per incrementi, fissando delle priorità sulle feature da sviluppare nell'immediato e chiedendo feedback al cliente man mano (in modo da avere la flessibilità)




Certo, ma dopo gli unit ed i test di integrazione è cosa buona e giusta anche far fare test a chi il programma lo deve usare ed, eventualmente, anche a persone esterne al tutto (poi dipende anche dal tipo di progetto che si sta portando avanti, quello che dico io è l'ideale... :) )



Quando hai grossi sistemi, i soli commenti nel codice non sono abbastanza :) , perché non ci si può mettere a leggere i sorgenti per capire cosa mette a disposizione un package o un intero applicativo ad es.



Più che altro c'è chi predica bene (sa queste cose) e poi razzola male (non le applica) :muro:

Sostanzialmente concordo su tutto. Sul discorso del prototipo vale il discorso dei test: dipende dal progetto e dalle tempistiche.
Fa' sempre piacere trovare persone competenti.;)

Fa' sempre piacere trovare persone competenti.;)

Si, almeno ogni tanto si scambia 4 chiacchiere, che la maggior parte delle volte gli interlocutori (anche se colleghi) sono delle capre in materia :stordita:

Si, almeno ogni tanto si scambia 4 chiacchiere, che la maggior parte delle volte gli interlocutori (anche se colleghi) sono delle capre in materia :stordita:
Per alcune mie conoscenze sarebbe un complimento...:muro:

secondo me vedendo i corsi di ingegneria del sw della mia università, il dott. Jacobson sarebbe contento. Io ho studiato un modello che somiglia molto al suo (ora non vorrei dire una boiata, ma era l'Agile).

Però io son convinto che specializzarsi serva, anche perchè, con la crisi che gira, conviene poco buttarsi nel lavoro oggi IMHO: vedo alcuni compagni di studio come vanno (e sto parlando di INGEGNERI) a lavorare venendo pagati 800€ netti e sfruttati con contratti a termine
Prima di trovare l'azienda attuale ho fatto dei colloqui in cui chiedevano senior developer che avessero almeno 5 anni di pratica e competenze da riempire un paio di fogli A0.
Nella migliore delle ipotesi offrivano 1000/1200 euro con contratto a tempo determinato. Risparmio le offerte delle ipotesi peggiori.
Purtroppo è così quasi ovunque....

Ingegneria Informatica, fatto in Analisi e Progettazione del Software (triennale), approfondirò in Ingegneria del Software (magistrale).
Abbiamo anche avuto come ospite, in facoltà, Craig Larman, autore di "Applying UML and patterns", un testo universitario di indubbia qualità

:O

L'intervento di questo signore è un misto di rimasticazioni di metodologie gia' note (processo iterativo), e sonore banalita' ( "contano le persone, non gli strumenti o i processi". Ma dai? ).
Mi sorprende che nel 2009 stiamo ancora a insegnare agli studenti metodologie di sviluppo general purpose invece di sfondarli di case studies ( e solo quelli ) finchè non gli scoppia la testa, come fanno nelle business schools americane.

L'intervento di questo signore è un misto di rimasticazioni di metodologie gia' note (processo iterativo), e sonore banalita' ( "contano le persone, non gli strumenti o i processi". Ma dai? ).
Prova ad andare nelle aziende e vedere se lo sanno che è tutta roba già nota ...
Resterai sorpreso a vedere quali strumenti e quale organizzazione adottano :muro:

Quando hai grossi sistemi, i soli commenti nel codice non sono abbastanza :)

Diciamo pure che i commenti nel codice non andrebbero scritti ne' in sistemi piccoli ne' tanto meno in sistemi grossi.
E sicuramente non si puo' pensare che i commenti facciano da documentazione, per questo esistono i functional test, ad esempio.

, perché non ci si può mettere a leggere i sorgenti per capire cosa mette a disposizione un package o un intero applicativo ad es.

In questo caso si parla di manuale d'uso e questo non e' a carico degli ingegneri, e si scrive al momento del rilascio dell'applicazione, non prima.

Ho letto di sfuggita che l'Ingegnere del Software non deve programmare, ma semplicemente dirigere il team: non ha alcun senso. E' impossibile dirigere un team di programmatori senza avere solidissime basi di programmazioni, e molti anni di esperienza. L'Ingegnere del Software deve essere un ottimo programmatore ed in grado di insegnarlo agl'altri.

Infine, non sono d'accordo con la definizione di Agile Development di Ivar: Agile non vuol dire scrivere codice senza architettura e rifattorizzarlo successivamente, ma vuol dire evolvere l'architettura mentre si scrive il codice e si accumulano informazioni sulla soluzione.

Devo spezzare una lancia in favore dell'università di Informatica di Torino a cui sono iscritto. Infatti nel corso di Sviluppo Software per Componenti ci sono state dette quasi tutte le cose che Jacobson ha raccontato. Quindi o non è poi così vero che a scuola non vengono dette certe cose, oppure io sono fortunato ad andare in una università valida.

Prova ad andare nelle aziende e vedere se lo sanno che è tutta roba già nota ...
Resterai sorpreso a vedere quali strumenti e quale organizzazione adottano :muro:

Dubito ci sia ancora qualcosa che possa sorprendermi in questo settore.
Tranne, forse, apprendere che un team ha portato a termine un progetto rispettando le deadline originali senza tagliare feature e senza overtime
( ahah, mi fa ridere solo scriverlo :) ).


Ho letto di sfuggita che l'Ingegnere del Software non deve programmare, ma semplicemente dirigere il team: non ha alcun senso. E' impossibile dirigere un team di programmatori senza avere solidissime basi di programmazioni, e molti anni di esperienza. L'Ingegnere del Software deve essere un ottimo programmatore ed in grado di insegnarlo agl'altri.

La frase che citi mi ricorda le tipiche sparate da ragazzino laureando in Ingsoft, sulla riga dell'intervento di poco sopra "programmare? roba da diplomati, noi studiamo per dominare il mondo.." ( ho parafrasato un po ma il senso e' sempre quello ).
Mi fa piacere che ogni tanto qualcuno ricordi il ruolo centrale del programmatore e come solo un programmatore con esperienza, che abbia scalato piu' livelli di seniority, possa coordinare lo sviluppo tecnico di un software.

Ho letto di sfuggita che l'Ingegnere del Software non deve programmare, ma semplicemente dirigere il team: non ha alcun senso. E' impossibile dirigere un team di programmatori senza avere solidissime basi di programmazioni, e molti anni di esperienza. L'Ingegnere del Software deve essere un ottimo programmatore ed in grado di insegnarlo agl'altri.

Non sono per niente d'accordo, un ingegnere del software non dovrebbe programmare, per quello basta un po' di intelligenza e tanta esperienza, esperienza che un ingegnere informatico non può avere.

Poi possiamo sempre dire che un ingegnere del software che sa ANCHE programmare sicuramente può integrarsi meglio in team piccoli dove non c'è molta gerarchia, ma normalmente pretendere che un ingegnere programmi è come chiedere ad un architetto di mettere i mattoni uno sopra all'altro: lo farà male e sarebbe sottoutilizzato.

Che poi il 90% delle aziende prende gli ingegneri per farli programmare è la realtà, ma questo non vuol dire (e lo dice pure jacobson) che sia sbagliato. Infatti vediamo bene da come funzionano molti prodotti che vengono buttati sul mercato senza una sana specifica o con specifiche approssimative; soprattutto nel mondo dei sistemi embedded e nell'automazione.
Ci troviamo quindi con cellulari che non funzionano bene, automobili con sistemi di sicurezza che non si attivano e prodotti elettronici con software poco intuitivi.
Ottimi programmatori sviluppano il software che però non è aderente alle specifiche e non si comporta come dovrebbe perchè non hanno le capacità di segiure e strutturare il progetto nel suo intero.

Non sono per niente d'accordo, un ingegnere del software non dovrebbe programmare, per quello basta un po' di intelligenza e tanta esperienza, esperienza che un ingegnere informatico non può avere.

Da Ingegnere del Software, ho difficolta' a gestire un team di 20 ottimi ingegneri pure avendo 20 anni di esperienza di programmazione alle spalle.

Non ho la piu' pallida idea di come qualcuno con limitata esperienza di programmazione possa insegnare al mio team a:
- scrivere codice semplice e mantenibile
- testare il codice
- produrre un'architettura semplice
- gestire milioni di righe di codice
- dare la giusta priorita' ai task

E' impossibile. Chi fa affermazioni come le tue semplicemente non ha mai dovuto gestire un team per un progetto complesso.

Un Ingegnere del Software deve avere un'enorme esperienza alle spalle. Non si puo' ingegnerizzare software senza questa esperienza, tanto meno dire agli altri come farlo.

Non sono per niente d'accordo, un ingegnere del software non dovrebbe programmare, per quello basta un po' di intelligenza e tanta esperienza, esperienza che un ingegnere informatico non può avere.


Credo che tu stia facendo confusione tra il TITOLO DI STUDIO ed il RUOLO nell'ambito di un azienda o di un organizzazione.

Se prendi uno appena uscito dall'universita con laurea/diploma/altro in ingegneria del software, ma senza esperienza pluriennale come programmatore in un team e gli affidi da subito un ruolo "da ingegnere del software", quel che ottieni al 90% sono solo problemi in piu.
Quindi il laureato/diplomato/ecc. deve saper programmare (e bene!) se vuole poi sperare di salire di ruolo.

sarà una mia impressione, ma MS rientra in pieno nel caso unsmart descritto da Jacobson :D

Microsoft usa un approccio di tipo iterativo-incrementale del tipo sincronizza e stabilizza.

Ha team composti da 3-8 persone e ad ogni programmatore è affiancata una persona che testa il codice (anch'esso programmatore), l'attività di testing è condotta in parallelo con lo sviluppo.

In ogni caso la teoria è una cosa, la pratica ben altra.

Non esiste un modello che vada bene per tutti, la bravura sta nel prendere un modello e plasmarlo sulle proprie esigenze ed esperienze, come dice lo stesso Jacobson, bisogna concentrarsi soprattutto sulle persone.

Credo che tu stia facendo confusione tra il TITOLO DI STUDIO ed il RUOLO nell'ambito di un azienda o di un organizzazione

Se prendi uno appena uscito dall'universita con laurea/diploma/altro in ingegneria del software, ma senza esperienza pluriennale come programmatore in un team e gli affidi da subito un ruolo "da ingegnere del software", quel che ottieni al 90% sono solo problemi in piu.
Mi dici dove ho parlato di uno appena uscito dall'università?
Io parlo di ruolo che uno ha e deve sviluppare fin dai primi giorni di lavoro, non passare dal programmatore, all'architetto software al consulente per la creazioni di nuove applicazioni.

Quindi il laureato/diplomato/ecc. deve saper programmare (e bene!) se vuole poi sperare di salire di ruolo.
Non è vero che è così.
In realtà un ingegnere informatico dovrebbe farsi le ossa imparando a seguire un team di programmatori seguendo il loro lavoro per capire se è aderente alle specifiche.
Per fare questo lavoro di testing delle specifiche non occorre essere programmatori, ma occorre uno schema di lavoro differente e più rigoroso, normalmente mal digerito dalle aziende correnti; che preferiscono puntare di più al marketing e alle campagne di vendita, sperperando soldi tra persone che hanno poco apporto tecnico.

Ad oggi in qualsiasi azienda di sviluppo software, l'iter è quello che descrivete: ingegnere del software che inizia a sviluppare, impara e fa esperienza, dimentica tutto quello che sa, regredisce ad un mero programmatore e quando arriva a fare il project manager non è più capace di fare quello per cui è nato.

Solo in aziende dove si producono applicazioni nelle quali non è concesso errore (es: applicazioni militari) si programma con queste medotologie più rigorose, proprio perchè il valore aggiunto è dato dalla affidabilità e dalla rigorosità del software.

Non è vero che è così.
In realtà un ingegnere informatico dovrebbe farsi le ossa imparando a seguire un team di programmatori seguendo il loro lavoro per capire se è aderente alle specifiche.
Per fare questo lavoro di testing delle specifiche non occorre essere programmatori, ma occorre uno schema di lavoro differente e più rigoroso, normalmente mal digerito dalle aziende correnti;


Insomma, tu appena laureato vuoi una grossa paga per non fare una mazza e stare tutto il giorno a rompere le scatole alla gente che lavora (i programmatori) :)
Ma poi, dopo un po di anni a fare questo lavoro da pseudo certificatore, per quale magia acquisisci le competenze per curare il design di un software complesso?


Ad oggi in qualsiasi azienda di sviluppo software, l'iter è quello che descrivete: ingegnere del software che inizia a sviluppare, impara e fa esperienza, dimentica tutto quello che sa, regredisce ad un mero programmatore e quando arriva a fare il project manager non è più capace di fare quello per cui è nato.


Questo coacervo di stupidaggini, a tratti insultante per chi fa la mia professione, andrebbe quotato frase per frase ma mi limito a chiederti: Che c'entra adesso il Project Manager con l'ingegnere del software?


Solo in aziende dove si producono applicazioni nelle quali non è concesso errore (es: applicazioni militari) si programma con queste medotologie più rigorose, proprio perchè il valore aggiunto è dato dalla affidabilità e dalla rigorosità del software.

Sulla base di quale esperienza fai queste affermazioni?
Io non ci ho lavorato nel militare ne' nell'aerospaziale, ma mi riesce difficile immaginare una industria che non viva primariamente in funzione delle deadline (se lavori su un nuovo missile teleguidato, hai interesse a completare lo sviluppo prima possibile perchè la concorrenza non sta certo con le mani in mano). Ed è quando devi rispettare dei tempi stringenti, svolgendo un lavoro che è sostanzialmente R&D, che sorgono i cavoli amari da cui nessuna metodologia di sviluppo appresa sui libri, per quanto rigorosa, ti può rendere immune.

Insomma, tu appena laureato vuoi una grossa paga per non fare una mazza e stare tutto il giorno a rompere le scatole alla gente che lavora (i programmatori) :)
Ma poi, dopo un po di anni a fare questo lavoro da pseudo certificatore, per quale magia acquisisci le competenze per curare il design di un software complesso?
Non ne hai, perchè non è compito tuo.

Un po' come dire che dopo anni a fare il muratore puoi permetterti di costruire un palazzo: impresa non impossibile perchè con l'esperienza si guadagna molta capacità. Però se tu avessi una azienda edile con una grossa commessa, faresti progettare un palazzo da un capocantiere o da un architetto/ingegnere edile?

La creazione di un software dovrebbe essere in mano ad un team intero in cui ci sono persone che scrivono il codice (tante), persone che verificano e sviluppano le specifiche (poche) e persone che adattano man mano le specifiche alle richieste del cliente (poche). Per quale motivo tu dici che una persona che cura le specifiche di un progetto lavori meno di uno che scrive codice?

Se poi mi dici che le poche persone che curano le specifiche dovrebbero anche conoscere la programmazione penso sia plausibile, la gavetta la deve fare chiunque. Però penso sia importante sviluppare una professione che non sia nè il programmatore nè il creatore di fuffa, che faccia da collante tra chi non comprende la programmazione e chi troppo legato al codice non sia capace di avere una visione più ad alto livello di un progetto.

Questo perchè il programmatore non può andare dal cliente a trattare, come non può essere chi tratta dal cliente che detta le specifiche ai programmatori.

Questo coacervo di stupidaggini, a tratti insultante per chi fa la mia professione, andrebbe quotato frase per frase ma mi limito a chiederti: Che c'entra adesso il Project Manager con l'ingegnere del software?
Mah, niente, in effetti il project manager è come dici tu uno che lavora poco e prende tanti soldi: da programmatore fortunatamente non ne ho conosciuti molti così ho potuto stilare anche le specifiche trattando direttamente con il cliente :D

Sulla base di quale esperienza fai queste affermazioni?
Io non ci ho lavorato nel militare ne' nell'aerospaziale, ma mi riesce difficile immaginare una industria che non viva primariamente in funzione delle deadline (se lavori su un nuovo missile teleguidato, hai interesse a completare lo sviluppo prima possibile perchè la concorrenza non sta certo con le mani in mano). Ed è quando devi rispettare dei tempi stringenti, svolgendo un lavoro che è sostanzialmente R&D, che sorgono i cavoli amari da cui nessuna metodologia di sviluppo appresa sui libri, per quanto rigorosa, ti può rendere immune.
A parte che non si dice "non ci ho lavorato", però ti assicuro che quando devi sviluppare in ADA il controllo dell'assetto di un elicottero, rispettando le specifiche date dall'elettronica e dal funzionamento del velivolo, oltre al rispettare le deadline avresti ben chiaro in testa che il tuo software deve funzionare alla perfezione: altrimenti vendono gli altri al posto tuo.
Faccio l'esempio di un elicottero da guerra ma possiamo anche parlare di una centrale nucleare o l'elettronica di un sistema di controllo ferroviario...

Lotto da 1 anno per l'applicazione di un sistema simile!!!!

ora sono riuscito ad ottenere un progetto basato su una archittettura semplice e aggiunta di Add-on su necessità/richeista.

...ma ancora mi chiedono "prima di iniziare fammi un preventivo di tempi e costi"...

non impareranno mai.

bah io di informatica ho fatto solo l'esame di Fondamenti di java fino all'hash table insomma(30/30 =D) siccome studio elettronica.Ma devo dire che le idee che ha espresso ci sono state spiegate,poi dipende dal docente,il mio era parecchio qualificato(laureato ad Howard e programmatore in una azienda).Cmq non sono totalmente d'accordo con il fatto di non usare i Tester: creare 1 programma è come creare una piccola creatura a cui vogliamo bene e quindi cerchiamo di non fargli male(anche inconsciamente!):stordita:

Non ne hai, perchè non è compito tuo.
Un po' come dire che dopo anni a fare il muratore puoi permetterti di costruire un palazzo: impresa non impossibile perchè con l'esperienza si guadagna molta capacità. Però se tu avessi una azienda edile con una grossa commessa, faresti progettare un palazzo da un capocantiere o da un architetto/ingegnere edile?


Prima dovresti spiegarmi quali analogie vedi tra lo sviluppo software e l'edilizia.


La creazione di un software dovrebbe essere in mano ad un team intero in cui ci sono persone che scrivono il codice (tante), persone che verificano e sviluppano le specifiche (poche) e persone che adattano man mano le specifiche alle richieste del cliente (poche). Per quale motivo tu dici che una persona che cura le specifiche di un progetto lavori meno di uno che scrive codice?


Insisti su questa conformita' alle specifiche come se fosse il cuore dell'ingsw, ma per come la vedo io l'analisi dei requirement è solo la punta dell'iceberg.
Tutta la parte hardcore viene DOPO che hai disegnato il simpatico diagrammino use case, e parte dalla configurazione dei macro-sistemi che compongono l'applicazione fino al design delle singole micro-componenti.
In fondo il software ha una struttura frattale: ad ogni livello di astrazione avrai sempre un mucchio di scatole nere che comunicano con altre scatole nere, che hanno un ciclo di vita, esibiscono behavior eccetera.
Il prog entra come junior e si occupa di scatolette piccole, per poi passare a scatole sempre più grandi e cosi' via fino ad avere una visione totale del sistema quando poi diventa lead, direttore tecnico o quello che e'.
E in ciascuno di questi livelli si trova ad operare, inevitabilmente, come ingegnere del software con responsabilità sempre più crescenti.
Non vedo cosa ci sia di alieno in questo.


Se poi mi dici che le poche persone che curano le specifiche dovrebbero anche conoscere la programmazione penso sia plausibile, la gavetta la deve fare chiunque. Però penso sia importante sviluppare una professione che non sia nè il programmatore nè il creatore di fuffa, che faccia da collante tra chi non comprende la programmazione e chi troppo legato al codice non sia capace di avere una visione più ad alto livello di un progetto.
Questo perchè il programmatore non può andare dal cliente a trattare, come non può essere chi tratta dal cliente che detta le specifiche ai programmatori.


A 'trattare' col cliente ci vanno commerciali e PM, scelti tra quelli che sembrano più fighi in giacca e cravatta :).
D'altro canto non puoi chiedere a una singola figura professionale di interfacciarsi col cliente, fare da middle management e, nei ritagli di tempo, ingegnerizzarti l'applicazione no?


Mah, niente, in effetti il project manager è come dici tu uno che lavora poco e prende tanti soldi: da programmatore fortunatamente non ne ho conosciuti molti così ho potuto stilare anche le specifiche trattando direttamente con il cliente :D


Mi devi aver letto nel pensiero perche' non ho detto niente sui PM.


A parte che non si dice "non ci ho lavorato", però ti assicuro che quando devi sviluppare in ADA il controllo dell'assetto di un elicottero, rispettando le specifiche date dall'elettronica e dal funzionamento del velivolo, oltre al rispettare le deadline avresti ben chiaro in testa che il tuo software deve funzionare alla perfezione: altrimenti vendono gli altri al posto tuo.
Faccio l'esempio di un elicottero da guerra ma possiamo anche parlare di una centrale nucleare o l'elettronica di un sistema di controllo ferroviario...

I concorrenti ti fanno le scarpe sul terreno dell'affidabilità solo se i problemi vengono a galla prima della chiusura del contratto, altrimenti la prima preoccupazione di ogni industria rimangono sempre i costi e il time to market.

post duplicato, sorry

Wow addirittura verso la fine non fa che dire quello che è già passato alla storia come KISS (Keep It Simple, Stupid!) ovvero fare uno scheletro semplice e poi farlo crescere.
Ha sparato un paio di fesserie (tipo criticare la pulizia del codice, e si vede che ha raramente messo mano in prima persona a codice fatto coi piedi da altri) e detto un paio di cose utili che si scoprono con l'esperienza.

Nulla di nuovo sotto il sole.

Non è vero che è così.
In realtà un ingegnere informatico dovrebbe farsi le ossa imparando a seguire un team di programmatori seguendo il loro lavoro per capire se è aderente alle specifiche.

Invece e' vero, e' cosi'. Ci si fa le ossa solo programmando, non seguendo un team di programmatori, perche' in questo caso non si hanno ne' le conoscenze ne' l'esperienza per prendere decisioni circostanziate.

Tu hai qualche esperienza diretta che indichi il contrario? Ce la puoi raccontare?

Da fek:
-------------------
Da Ingegnere del Software, ho difficolta' a gestire un team di 20 ottimi ingegneri pure avendo 20 anni di esperienza di programmazione alle spalle.

Non ho la piu' pallida idea di come qualcuno con limitata esperienza di programmazione possa insegnare al mio team a:
- scrivere codice semplice e mantenibile
- testare il codice
- produrre un'architettura semplice
- gestire milioni di righe di codice
- dare la giusta priorita' ai task

E' impossibile. Chi fa affermazioni come le tue semplicemente non ha mai dovuto gestire un team per un progetto complesso.
--------------------------------

scusa ma il tuo compito non dovrebbe essere quello di insegnare, tu dovresti solo coordinare persone già capaci di lavorare.... capisco che questa non sia spesso la realtà lavorativa che si deve affrontare in pratica, ma da quello che dici non stai facendo veramente il project manager.

In generale non è detto che il prodotto che sati sviluppando sia fatto solo di software, potresti anche avere parti elettroniche, meccaniche, problemi sui materiali, sui processi di fabbricazione ecc... secondo te uno potrebbe essere esperto di tutto? se poi ci limitiamo a considerare una semplice software hause ok, ma in generale le cose sono molto diverse.


Da Dreadnought
-----------------------------
però ti assicuro che quando devi sviluppare in ADA il controllo dell'assetto di un elicottero, rispettando le specifiche date dall'elettronica e dal funzionamento del velivolo, oltre al rispettare le deadline avresti ben chiaro in testa che il tuo software deve funzionare alla perfezione: altrimenti vendono gli altri al posto tuo.
Faccio l'esempio di un elicottero da guerra ma possiamo anche parlare di una centrale nucleare o l'elettronica di un sistema di controllo ferroviario...
-------------------------------

non conosco l'ambito militare ma non penso che si discosti molto da quello medicale di cui mi occupo. Mi viene difficile pensare per questo tipo di applicazioni modelli "rigidi" come quello a cascata, qui tanto criticato, visto che per queste applicazioni non è sufficiente verificare semplicemente che il software funzioni ma bisogna invece documentare molto pesantemente tutto il processo di sviluppo applicato per dimostrare la bontà del software prodotto.


Da Marziano

-------------------------------
Insisti su questa conformita' alle specifiche come se fosse il cuore dell'ingsw, ma per come la vedo io l'analisi dei requirement è solo la punta dell'iceberg.
-------------------------------

Scusa ma i requirements sono l'input di tutto, se sbagli quelli non puoi di certo ottenere il prodotto che desideri.
Forese bisognerebbe ricordare che se voglio produrre una macchina rossa, non mi interessa svilupparne una blu perchè alla fine del processo mi accorgo che rossa non riesco a farla!


Che poi spesso nelle aziende la realtà non sia questa è un loro grosso problema, che sprecano soldi e risorse in modo inutile... ciò non toglie che quello che viene insegnato sia il modo corretto di fare.

Cia Ale, spero che la discussione continui perchè interessante...

Scusate:

Mi viene difficile NON pensare per questo tipo di applicazioni A modelli "rigidi" come quello a cascata, qui tanto criticato, visto che per queste applicazioni non è sufficiente verificare semplicemente che il software funzioni ma bisogna invece documentare molto pesantemente tutto il processo di sviluppo applicato per dimostrare la bontà del software prodotto.

scusa ma il tuo compito non dovrebbe essere quello di insegnare, tu dovresti solo coordinare persone già capaci di lavorare.... capisco che questa non sia spesso la realtà lavorativa che si deve affrontare in pratica, ma da quello che dici non stai facendo veramente il project manager.

Il mio compito e' assicurarmi che il prodotto sia rilasciato secondo le specifiche, in tempo e nel budget allocato.
Un programmatore che non impara anno dopo anno e' come un Ingegnere del Software che pensa di poter dirigere un team di Ingegneri senza saper programmare: e' inutile.

Quindi il mio compito e' anche migliorare il team che ho a disposizione, esplorare nuove metodologie, migliorare quelle correnti e migliorare il codice prodotto dal team, migliorare le pratiche di sviluppo.

Prima dovresti spiegarmi quali analogie vedi tra lo sviluppo software e l'edilizia.


DP GOF? Vediamo se la capisci...

Wow addirittura verso la fine non fa che dire quello che è già passato alla storia come KISS (Keep It Simple, Stupid!) ovvero fare uno scheletro semplice e poi farlo crescere.
Ha sparato un paio di fesserie (tipo criticare la pulizia del codice, e si vede che ha raramente messo mano in prima persona a codice fatto coi piedi da altri) e detto un paio di cose utili che si scoprono con l'esperienza.

Nulla di nuovo sotto il sole.

Ma sei proprio te? cioè... davvero? :eek:
Anche qua? :D

PGB

--------------------
Quindi il mio compito e' anche migliorare il team che ho a disposizione, esplorare nuove metodologie, migliorare quelle correnti e migliorare il codice prodotto dal team, migliorare le pratiche di sviluppo.
--------------------

Vero, se ti riferisci al solo ambito del software. In generale però è impossibile che tu sappia tutto (informatica, elettronica, meccanica...) e quindi è impensabile che sia il project manager a insegnare competenze specifiche, puoi solo far in modo che venga rispettata una metodologia e adoperarti affinchè essa venga migliorata nel tempo. Per il miglioramento dei componenti del team dipende, a seconda del caso e del badget puoi decidere se richiedere altro personale, organizzare un corso per far cresecre la competenza di uno o più membri o semplicemente decidere che il progetto non è fattibile con le risorse a disposizione (da ingegnere sicuramente la cosa più difficile, vista la mentalità da "tutto si può fare!")

Ciao Ale

il mio prof mi ha fatto na testa con UML,OCL, programmazione strutturata con pre e post condition..........ma debbo dire che son servite :-)

Ecco quello che ha creato l'UML :D

Te possino....:sofico:

Linguaggio inutile.

Cmq la PoliMI tutto quello che ha detto costui viene assolutamente insegnato nel corso di Ingegneria del Software :)

"Il" volevi dire?


Eh ma lo sanno tutti al PoliMi ci sono tutti i più migliori che ci sarebbino potuti essere
:asd: :D


Io comunque, sinceramente, vorrei vederli tutti i corsi in cui le idee che passano solo quelle dell'esimio Ivar.
Se si lamenta delle università nordiche, le stesse che hanno dato i natali alle persone che più o meno in Europa hanno fatto la storia dell'Informatica, dubito fortemente che in Italia non troverebbe almeno le stesse anomalie e criticità.

L'approccio da noi che va per la maggiore è il Waterfall.
Di metodologie agili e affini non se ne parla manco di striscio, neanche in IngSW2.
Chi lo fa rappresenta la schiera di mosche bianche sparse sul territorio italiano.

Invece e' vero, e' cosi'. Ci si fa le ossa solo programmando, non seguendo un team di programmatori, perche' in questo caso non si hanno ne' le conoscenze ne' l'esperienza per prendere decisioni circostanziate.
Beh questo è il tuo caso, ma come puoi dire che è la struttura vincente?

Prendi l'esempio del programmatore di C/ASM che ha iniziato anni fa e si è fatto per 20 anni le ossa su C diventando un superesperto. Questo però non comprende la struttura ad oggetti dei linguaggi di programmazione moderna, e anzi si ostina a dire che C è più performante quindi migliore di Python, Java e C++ tu lo metteresti a dirigere un team di programmatori?
In questo caso il tuo discorso vale ancora oppure inizi a ritrattare dicendo che un programmatore deve anche evolversi e comprendere le strutture software ad un livello più alto?

Tu hai qualche esperienza diretta che indichi il contrario? Ce la puoi raccontare?
No, non sono figo come te che lavori in una industria che sviluppa videogames quindi non posso sboroneggiare sull'argomento vantandomene sul forum :asd:

Però ti posso dire che l'azienda dove lavoro vende tra le tante cose software (oggetto delle mie consulenze da clienti) sviluppati in india, dove usano le metodologie di programmazione sbagliate indicate da jacobson: senza struttura, senza documentazione e che seguono processi di produzione economici che puntano solo al budget e alle deadline.
Per lo più si seguono schemi waterfall, dove non c'è chiaramente dialogo tra chi programma e chi studia l'evoluzione degli applicativi, così ogni anello della catena può solo sperare che chi sta sotto faccia il suo lavoro "correttamente".

In caso contrario chi fa testing o chi sta sul cliente apre un "change" e si tenta di risolovere il problema: procedimento lungo che spesso lascia il cliente a piedi fino alla nuova release del software.

Non ti sembra un attimo migliorabile questo processo?

Questo si che è un homo novus! :D

Beh questo è il tuo caso, ma come puoi dire che è la struttura vincente?

Prendi l'esempio del programmatore di C/ASM che ha iniziato anni fa e si è fatto per 20 anni le ossa su C diventando un superesperto. Questo però non comprende la struttura ad oggetti dei linguaggi di programmazione moderna, e anzi si ostina a dire che C è più performante quindi migliore di Python, Java e C++ tu lo metteresti a dirigere un team di programmatori?

Tu metteresti un ingegnere idraulico che ha per vent'anni lavorato su dighe a capo, per la prima volta, di un progetto di un grattacielo?

Non credo.

Il fatto di avere esperienza e di doversi impegnare direttamente nel lavoro del team non può prescindere dal contesto in cui devi operare e non credo fosse quello che fek intendeva dire.
E' ovvio che puoi dirigere un team e sviluppare con il team solo se hai il know-how per farlo.
Se sai sviluppare solo in Clipper non vedo come tu possa diventare il tech-leader della prossima interfaccia di Windows basata su C# e WPF (sparo due tecnologie).

Non capisco il tuo esempio che cosa miri a confutare. :mbe:


In questo caso il tuo discorso vale ancora oppure inizi a ritrattare dicendo che un programmatore deve anche evolversi e comprendere le strutture software ad un livello più alto?


E' ovvio.
Ma, dopo C ed Assembly il successivo livello di di astrazione più alto non è l'UML.

Beh questo è il tuo caso, ma come puoi dire che è la struttura vincente?

Prendi l'esempio del programmatore di C/ASM che ha iniziato anni fa e si è fatto per 20 anni le ossa su C diventando un superesperto. Questo però non comprende la struttura ad oggetti dei linguaggi di programmazione moderna, e anzi si ostina a dire che C è più performante quindi migliore di Python, Java e C++ tu lo metteresti a dirigere un team di programmatori?
In questo caso il tuo discorso vale ancora oppure inizi a ritrattare dicendo che un programmatore deve anche evolversi e comprendere le strutture software ad un livello più alto?

Il ragionamento regge lo stesso. Non necessariamente chi programma ha skill che permettano di essere team-leader o è in grado di apprenderle.

No, non sono figo come te che lavori in una industria che sviluppa videogames quindi non posso sboroneggiare sull'argomento vantandomene sul forum :asd:

Però ti posso dire che l'azienda dove lavoro vende tra le tante cose software (oggetto delle mie consulenze da clienti) sviluppati in india, dove usano le metodologie di programmazione sbagliate indicate da jacobson: senza struttura, senza documentazione e che seguono processi di produzione economici che puntano solo al budget e alle deadline.
Per lo più si seguono schemi waterfall, dove non c'è chiaramente dialogo tra chi programma e chi studia l'evoluzione degli applicativi, così ogni anello della catena può solo sperare che chi sta sotto faccia il suo lavoro "correttamente".

In caso contrario chi fa testing o chi sta sul cliente apre un "change" e si tenta di risolovere il problema: procedimento lungo che spesso lascia il cliente a piedi fino alla nuova release del software.

Non ti sembra un attimo migliorabile questo processo?

Se usano un approccio waterfall hanno ben poco da spartire con Jacobson.

scusa ma il tuo compito non dovrebbe essere quello di insegnare, tu dovresti solo coordinare persone già capaci di lavorare.... capisco che questa non sia spesso la realtà lavorativa che si deve affrontare in pratica, ma da quello che dici non stai facendo veramente il project manager.


L'articolo di cui si discute però non è rivolto ai PM, che non sono dei tecnici, ma ai programmatori/ingegneri del sw.
Di questi ultimi si discute contestando, nello specifico, la visione di chi pensa che sulla base di una esperienza puramente accademica, e senza aver scritto una riga di codice nella vita, si possa ingegnerizzare un software.


Scusa ma i requirements sono l'input di tutto, se sbagli quelli non puoi di certo ottenere il prodotto che desideri.
Forese bisognerebbe ricordare che se voglio produrre una macchina rossa, non mi interessa svilupparne una blu perchè alla fine del processo mi accorgo che rossa non riesco a farla!


Non ho detto che i requirements non sono importanti, ma tra le cause di fallimento di un progetto, sia in letteratura che nella pratica, vengono sicuramente all'ultimo posto.
In special modo se poi hai un committente rompiballe come quelli che ho conosciuto io. In tal caso stai sicuro che l'auto uscirà del colore giusto ( che nel frattempo sarà stato cambiato in corso d'opera 57655 volte :) ).

DP GOF? Vediamo se la capisci...

Purtroppo no, mi devi spiegare tu che c'entrano i design pattern con l'edilizia.
Non sto sfidando nessuno eh, voglio capire sinceramente perchè sta storia del muratore e dell'architetto esce fuori praticamente sempre quando si parla di sviluppo sw, mi incuriosisce il suo fondamento.

L'articolo di cui si discute però non è rivolto ai PM, che non sono dei tecnici, ma ai programmatori/ingegneri del sw.
Di questi ultimi si discute contestando, nello specifico, la visione di chi pensa che sulla base di una esperienza puramente accademica, e senza aver scritto una riga di codice nella vita, si possa ingegnerizzare un software.

Io invece credo sia rivolto proprio a tutti.
In quel che affermi c'è una distorsione (italiana) della figura del project manager.
In Italia si è creato l'artifizio del project manager per cui è a capo di un progetto o di un team ma non ha (sufficiente) know-how tecnico.
Cosa molto vera nelle grandi aziende di consulenza, dove si tende ad una struttura fortemente piramidale.
Il che per me però resta una cosa priva di logica perché per rimanere alla casistica edilizia è come se un architetto o un ingegnere non conoscessero i materiali utilizzati in una costruzione, come questi e le misure di portanti ed altri elementi della stessa inficiano sulla stabilità, resistenza a fattori esterni ecc.

Ma all'estero non funziona così.
Il Project Manager che in realtà non esiste ma viene chiamato spesso Team Leader è uno sviluppatore.
Se vedete i webcast dei vari Channel MSDN vi rendete conto che tutte le persone che ricoprono incarichi a più alto livello nello sviluppo software di un prodotto sono anch'essi sviluppatori.
Gli stessi Brin e Page sviluppano al fianco dei dipendenti.
Non solo è logico, ma è anche una forma di abbattimento della differenza sociale tra sottoposto e superiore. Se lui è lì è perché ci è arrivato facendo quel che fai tu, magari prima di te e forse meglio di te.
Ciò non toglie che puoi arrivare un giorno a ricoprire quell'incarico.
E' molto più meritocratico e democratico.
Ed ecco la differenza sostanziale che separa l'Italia dall'estero, mondo anglosassone in primis.



Purtroppo no, mi devi spiegare tu che c'entrano i design pattern con l'edilizia.
Non sto sfidando nessuno eh, voglio capire sinceramente perchè sta storia del muratore e dell'architetto esce fuori praticamente sempre quando si parla di sviluppo sw, mi incuriosisce il suo fondamento.

Curioso anche io :)

Dunque come al solito sta uscendo un macello di discussione .

1) ing informatica non è solo programmazione , un ingegnere informatico che fa il solo lavoro di programmatore è riduttivo . E questo lo disse persino Mandrioli alla mia proclamazione di laurea triennale (anche se capisco questo vada quasi a detrimento di quanto ho appena affermato :asd:)

2)il polimi in 2 righe cosa scrive di ing informatica :
INGEGNERIA INFORMATICA ord. 509
sede di Milano Leonardo, a.a. 2008/2009
Laurea Specialistica/Magistrale
Presentazione
Il corso e` finalizzato alla formazione di ingegneri informatici specializzati nella ideazione, realizzazione e gestione di sistemi informatici moderni, con particolare riguardo alla convergenza tra le tecnologie informatiche, elettroniche e delle telecomunicazioni e allo sviluppo di applicazioni e servizi basati su Internet e sul Web. La figura professionale prevista coniuga una solida preparazione scientifica e tecnologica con nuove competenze di carattere interdisciplinare, incentrate sia sugli aspetti comunicativi, sia sugli aspetti manageriali dell'ICT. Gli ambiti applicativi di maggior interesse includono l'e-business (in senso lato), l'e-governement, l'editoria on-line, i sistemi informativi basati sul Web, le applicazioni grafiche e multimediali, le applicazioni per i beni culturali, ecc.

e ancora

Il Corso di Laurea in Ingegneria Informatica si propone di fornire una solida formazione di base, che consenta di interagire con gli specialisti di tutti i settori dell’ingegneria tradizionale, di comprendere il funzionamento dei sistemi complessi di cui è intessuta la società postindustriale, di sviluppare ed utilizzare le tecnologie dell’informatica contribuendo, nella misura consentita dalle conoscenze attuali, a valutarne e risolverne i problemi.

Mira inoltre a sviluppare un'approfondita professionalità nell’informatica e a trasmettere competenze relative al mondo della tecnologia dell’informazione in generale: vale a dire, al mondo dell’automatica, dell’elettronica e delle telecomunicazioni.

È proprio questa impostazione che distingue nettamente il laureato in Ingegneria Informatica dagli informatici di formazione non ingegneristica.

Le conoscenza di base vengono sviluppate soprattutto nel corso dei primi tre semestri durante i quali lo studente acquisisce gli elementi essenziali delle discipline scientifiche che costituiscono le fondamenta indispensabili degli studi di ingegneria (fisica ma soprattutto matematiche, ossia analisi, geometria, algebra, logica matematica, statistica e calcolo delle probabilità).
La preparazione informatica è concreta ma di tipo fondazionale, ed è accompagnata dai fondamenti delle altre discipline dell'ingegneria dell'Informazione, quali l'Automatica, le Telecomunicazioni e l'Elettronica.

La preparazione ingegneristica è completata tramite due diversi percorsi formativi, denominati Generale e Specifico.
Il percorso Generale prevede materie di tipo ingegneristico anche in settori esterni all'Ingegneria dell'Informazione (come ad esempio la Chimica, la Fisica Tecnica, la Meccanica) mentre il percorso Specifico prevede materie ingegneristiche all'interno del settore dell'Informazione e attività progettuali specifiche di Ingegneria Informatica.


Anche solo guardando il piano di studi si capisce che le competenze di un ing. informatico sono ben più ampie della sola programmazione (che poi vabbè può essere più o meno complessa etc .)

Risulta anche chiaro , sempre guardando i piani di studi, che un ing. informatico debba sapere cos'è la programmazione , infatti è fatta in alcuni esami obbligatori ,anche se viene detto esplicitamente che i linguaggi di programmazione si suppone uno se li impari in seguito a seconda di quello che più si adatta all'applicazione da realizzare.Cioè ti insegno java e C e le idee alla base , poi un domani se ti serve imparare phyton te lo impari te per conto tuo , le capacità per farlo rapidamente dovresti averle.

La programmazione per un ing. non è lo scopo finale , non studia per imparare a programmare , bensì impara a programmare per risolvere problematiche e per implementare algoritmi e modelli .

L'idea è che c'è un problema e l'ing. informatico utilizza le sue conoscenze per risolverlo. Ad esempio potrebbe essere che fastweb mi contatta e mi dice che vuole una valutazione delle prestazioni della sua rete e delle ottimizzazioni possibili e magari pure la realizzazione di un software per modellare il suo sistema da utilizzare per ulteriori valutazioni e previsioni.
Oppure può anche voler dire valutare diverse architetture e diverse soluzioni software e sceglierne una per poi implementarla .

Per cose del genere cosa fate chiamate il programmatore diplomato anche con 10 anni di esperienza? No chiamate l'ing. informatico (ma anche telecomunicazioni o altro eh), poi l'esperienza o meno è un altro discorso: è chiaro che il neo laureato andrà affiancato da qualcuno esperto , farà gavetta etc etc , ma le competenze richieste da problemi del genere richiedono un approccio ingegneristico.

Ovviamente tali problematiche possono avere difficoltà molto diverse e criticità molto eterogenee.

Infine aggiungo che è scontato che appena uscito dall'università ci sia cmq molta esperienza da fare e molto ancora da imparare prima di fare qualcosa di molto serio . Nessuno pretende di uscire dall'uni e diventare project manager per un progetto importantissimo .
Poi vabbè tra questo e passare il tempo a scrivere codice e basta ci sono tante via di mezzo.


P.S.
Cmq se non c'è chiarezza qui , su un sito tecnologico, su quali siano i compiti e le mansioni di un ing informatico non mi stupisce che poi le aziende (specialmente italiane) li prendano e li mettano a programmare e basta senza sfruttarne le peculiarità o non capendole . Poi vabbè è anche vero che l'approccio ingegneristico è utile in moltissimi campi, pura programmazione inclusa , però....

P.P.S.
Io parlo di ing. informatica . Ing. del software io la conosco solo come una delle materie all'interno del corso di studi di ing. informatica . In questo 3d sono state usate quasi a sinonimi , ma per quanto mi riguarda non lo sono , quindi preciso onde evitare fraintendimenti.

PPPS
Scusate i numerosi refusi , ho scritto molto velocemente

Beh questo è il tuo caso, ma come puoi dire che è la struttura vincente?

Si', ci puoi portare un esempio contrario?


No, non sono figo come te che lavori in una industria che sviluppa videogames quindi non posso sboroneggiare sull'argomento vantandomene sul forum :asd:

Non capisco perche' la stai mettendo sul personale. Avrai finito gli argomenti.
Qui non si sta vantando e non sta sboroneggiando nessuno: ci limitiamo a riportare la nostra esperienza e a discuterne. Per cortesia comportati in maniera civile e non lasciarti andare ad uscite cosi' puerili.

L'articolo di cui si discute però non è rivolto ai Purtroppo no, mi devi spiegare tu che c'entrano i design pattern con l'edilizia.
Non sto sfidando nessuno eh, voglio capire sinceramente perchè sta storia del muratore e dell'architetto esce fuori praticamente sempre quando si parla di sviluppo sw, mi incuriosisce il suo fondamento.
I Design Pattern nascono per l'edilizia, per mano di tal Christopher Alexander con il libro A Pattern Language.
La similitudine tra edilizia è meno campata in aria di quanto sembra.
Ti porto un esempio che amo particolarmente e che ho spesso usato parlando con commeciali e pm :sofico:
Se tu devi tirare su un piccolo muro a secco, chiami un muratore e lo fai fare.
Se devi aggiungere una stanza a casa tua, pobabilmente ti appoggerai ad un qualunque buon geometra per il progetto ed a una qualunque ditta edile per il lavoro pratico.
Se vuoi costruire una villetta su un tuo terreno, probabilmente cercherai un geometra o architetto che abbia esperienza e una impresa edile che abbia costruito altre villette.
Nel momento in cui tu volessi costruire un palazzo di 10 piani cercheresti altrove.
Non parliamo per un grattacielo, a quel punto la struttura dovrebbe essere davvero ben organizzata, onde evitare problemi disdicevoli.
Questo perchè le complessità non sono lineari.
Non è detto che chi sa tirare su un muro a secco, sia in grado di metterne insieme quattro e fare una stanza.
Eccetera eccetera fino al grattacielo.
Per quanto riguarda i dp, normalmente in edilizia per risolvere problemi comuni si tendono ad usare soluzioni conosciute e rodate.
Esattamante come si dovrebbe fare con l'informatica.
La similitudine tra edilizia e informatica nasce dal fatto che stringi stringi si tratta sempre da costruire/riparare.
Le figure professionali dell'edilizia trovano sempre una similitudine nel mondo dello sviluppo, tanto quanto le problematiche.
Spero di essere stato esauriente, e scusa per il giochetto di prima.
Se ho detto qualche m*****ata non torturatemi.:D

I Design Pattern nascono per l'edilizia, per mano di tal Christopher Alexander con il libro A Pattern Language.
La similitudine tra edilizia è meno campata in aria di quanto sembra.
Ti porto un esempio che amo particolarmente e che ho spesso usato parlando con commeciali e pm :sofico:
Se tu devi tirare su un piccolo muro a secco, chiami un muratore e lo fai fare.
Se devi aggiungere una stanza a casa tua, pobabilmente ti appoggerai ad un qualunque buon geometra per il progetto ed a una qualunque ditta edile per il lavoro pratico.
Se vuoi costruire una villetta su un tuo terreno, probabilmente cercherai un geometra o architetto che abbia esperienza e una impresa edile che abbia costruito altre villette.
Nel momento in cui tu volessi costruire un palazzo di 10 piani cercheresti altrove.
Non parliamo per un grattacielo, a quel punto la struttura dovrebbe essere davvero ben organizzata, onde evitare problemi disdicevoli.
Questo perchè le complessità non sono lineari.
Non è detto che chi sa tirare su un muro a secco, sia in grado di metterne insieme quattro e fare una stanza.
Eccetera eccetera fino al grattacielo.
Per quanto riguarda i dp, normalmente in edilizia per risolvere problemi comuni si tendono ad usare soluzioni conosciute e rodate.
Esattamante come si dovrebbe fare con l'informatica.
La similitudine tra edilizia e informatica nasce dal fatto che stringi stringi si tratta sempre da costruire/riparare.
Le figure professionali dell'edilizia trovano sempre una similitudine nel mondo dello sviluppo, tanto quanto le problematiche.
Spero di essere stato esauriente, e scusa per il giochetto di prima.
Se ho detto qualche m*****ata non torturatemi.:D

a me pare calzante come paragone.:)

La similitudine tra edilizia e informatica nasce dal fatto che stringi stringi si tratta sempre da costruire/riparare.
Le figure professionali dell'edilizia trovano sempre una similitudine nel mondo dello sviluppo, tanto quanto le problematiche.
Spero di essere stato esauriente, e scusa per il giochetto di prima.
Se ho detto qualche m*****ata non torturatemi.:D

C'e' una differenza fondamentale fra Ingegneria Civile/Edile e Ingegneria del Software: la prima scienza ha migliaia di anni di esperienza alle spalle. La seconda no.

Da qui in poi le metodologie di soluzione dei problemi divergono totalmente e le analogie cadono, perche' puoi stimare con un errore spesso inferiore al 5% il costo di un ponte o di una casa, ad esempio, mentre se riesci a stimare con un errore inferiore al 100% il costo di un software stappi le bottiglie di champagne.

C'e' una differenza fondamentale fra Ingegneria Civile/Edile e Ingegneria del Software: la prima scienza ha migliaia di anni di esperienza alle spalle. La seconda no.

Da qui in poi le metodologie di soluzione dei problemi divergono totalmente e le analogie cadono, perche' puoi stimare con un errore spesso inferiore al 5% il costo di un ponte o di una casa, ad esempio, mentre se riesci a stimare con un errore inferiore al 100% il costo di un software stappi le bottiglie di champagne.
Non sono le metodologie ma i processi che differiscono. Anche se stiamo a spaccare il capello sui sostantivi.
Questo perchè le specifiche di un progetto edilizio se cambiano lo fanno prima della loro effettiva messa in opera.
E per questo si approccia a cascata. Cosa che nel software equivale al suicidio.
Nel software le specifiche sono sempre soggette al cambiamento, per definizione. E in qualunque fase del progetto.
Per curiosità, le stime raddoppiano sistematicamente? Capisco un 20% che ci può stare ma può essere previsto, ma 100% mi sembra tantino.

Non sono le metodologie ma i processi che differiscono. Anche se stiamo a spaccare il capello sui sostantivi.
Questo perchè le specifiche di un progetto edilizio se cambiano lo fanno prima della loro effettiva messa in opera.
E per questo si approccia a cascata. Cosa che nel software equivale al suicidio.
Nel software le specifiche sono sempre soggette al cambiamento, per definizione. E in qualunque fase del progetto.
Per curiosità, le stime raddoppiano sistematicamente? Capisco un 20% che ci può stare ma può essere previsto, ma 100% mi sembra tantino.

A parte l'uso dei sostantivi, sul resto sono d'accordo con te.

A parte l'uso dei sostantivi, sul resto sono d'accordo con te.
;)

Si', ci puoi portare un esempio contrario?
Scusa la tua risposta non ha senso con la mia domanda, almeno in italiano.

Non capisco perche' la stai mettendo sul personale. Avrai finito gli argomenti.
Qui non si sta vantando e non sta sboroneggiando nessuno: ci limitiamo a riportare la nostra esperienza e a discuterne. Per cortesia comportati in maniera civile e non lasciarti andare ad uscite cosi' puerili.
L'hai messa tu sul personale chiedendomi se sono stato DIRETTAMENTE partecipe di una esperienza ti ricordo, forse perchè vuoi arrogarti di insegnare a tutti come si deve lavorare solo perchè te hai una ottima esperienza nel campo dello sviluppo di videogames?

Perchè mi chiedi di portarti esempi di esperienza diretta?
Esempi che tra l'altro ti ho portato ma mi pare che tu faccia finta di non vedere... :rolleyes:

Dunque come al solito sta uscendo un macello di discussione .

1) ing informatica non è solo programmazione , un ingegnere informatico che fa il solo lavoro di programmatore è riduttivo . E questo lo disse persino Mandrioli alla mia proclamazione di laurea triennale (anche se capisco questo vada quasi a detrimento di quanto ho appena affermato :asd:)

2)il polimi in 2 righe cosa scrive di ing informatica :

Quoto e sottoscrivo.

La programmazione e l'esperienza della programmazione dovrebbero essere una parte del tutto sia nell'insegnamento, sia nella carriera lavorativa.

Mi dici dove ho parlato di uno appena uscito dall'università?

Era quel che si poteva intendere quando hai scritto:
Non sono per niente d'accordo, un ingegnere del software non dovrebbe programmare, per quello basta un po' di intelligenza e tanta esperienza, esperienza che un ingegnere informatico non può avere.

Nota bene, hai proprio scritto: "esperienza che un ingegnere informatico non può avere".
Per non averla significa che e' approdato quasi subito a ruoli che non richiedono capacita di programmazione.


Io parlo di ruolo che uno ha e deve sviluppare fin dai primi giorni di lavoro, non passare dal programmatore, all'architetto software al consulente per la creazioni di nuove applicazioni.


Il punto e' che quello che tu vuoi ottenere non corrisponde necessariamente a quel che vuole l'azienda, specialmente perche come Jacobson ha enfatizzato piu volte bisogna saper gestire bene anche il fattore umano.


Non è vero che è così.
In realtà un ingegnere informatico dovrebbe farsi le ossa imparando a seguire un team di programmatori seguendo il loro lavoro per capire se è aderente alle specifiche.

Non e' solo quello, le specifiche non cadono dal cielo ed a volte sono errate.
Poi c'e' il non trascurabile problema che in un team se si gestisce male il fattore umano si creano i presupposti per situazioni disastrose (comunicazione insufficiente tra le persone coinvolte ecc. ecc.).
Visto che i ruoli "da vero ingegnere" sono pochi e' inevitabile che chi ha il titolo e potenzialmente potrebbe ricoprire il ruolo viene prima messo alla prova in altre mansioni all'interno di un team.


Per fare questo lavoro di testing delle specifiche non occorre essere programmatori, ma occorre uno schema di lavoro differente e più rigoroso, normalmente mal digerito dalle aziende correnti; che preferiscono puntare di più al marketing e alle campagne di vendita, sperperando soldi tra persone che hanno poco apporto tecnico.

Questo e' un altro discorso e guardacaso spesso all'origine di esso c'e' qualcuno che "non dovrebbe saper programmare".


Ad oggi in qualsiasi azienda di sviluppo software, l'iter è quello che descrivete: ingegnere del software che inizia a sviluppare, impara e fa esperienza, dimentica tutto quello che sa, regredisce ad un mero programmatore e quando arriva a fare il project manager non è più capace di fare quello per cui è nato.

Ma se come dici tu "regredisce", significa solo che non si e' tenuto aggiornato
(succede sin troppo spesso e non e' limitato ai settori "tecnico-scientifici").


Solo in aziende dove si producono applicazioni nelle quali non è concesso errore (es: applicazioni militari) si programma con queste medotologie più rigorose, proprio perchè il valore aggiunto è dato dalla affidabilità e dalla rigorosità del software.

Di solito quelle aziende se prendono qualcuno come dici tu per ruoli "da ingegnere del software" o lo assumono gia rodato in ruoli simili nello stesso settore o in settori affini, oppure pescano tra gli sviluppatori interni che potenzialmente hanno tutti i requisiti minimi.

I Design Pattern nascono per l'edilizia, per mano di tal Christopher Alexander con il libro A Pattern Language.
La similitudine tra edilizia è meno campata in aria di quanto sembra.
Ti porto un esempio che amo particolarmente e che ho spesso usato parlando con commeciali e pm :sofico:
Se tu devi tirare su un piccolo muro a secco, chiami un muratore e lo fai fare.
Se devi aggiungere una stanza a casa tua, pobabilmente ti appoggerai ad un qualunque buon geometra per il progetto ed a una qualunque ditta edile per il lavoro pratico.
Se vuoi costruire una villetta su un tuo terreno, probabilmente cercherai un geometra o architetto che abbia esperienza e una impresa edile che abbia costruito altre villette.
Nel momento in cui tu volessi costruire un palazzo di 10 piani cercheresti altrove.
Non parliamo per un grattacielo, a quel punto la struttura dovrebbe essere davvero ben organizzata, onde evitare problemi disdicevoli.
Questo perchè le complessità non sono lineari.
Non è detto che chi sa tirare su un muro a secco, sia in grado di metterne insieme quattro e fare una stanza.
Eccetera eccetera fino al grattacielo.
Per quanto riguarda i dp, normalmente in edilizia per risolvere problemi comuni si tendono ad usare soluzioni conosciute e rodate.
Esattamante come si dovrebbe fare con l'informatica.
La similitudine tra edilizia e informatica nasce dal fatto che stringi stringi si tratta sempre da costruire/riparare.
Le figure professionali dell'edilizia trovano sempre una similitudine nel mondo dello sviluppo, tanto quanto le problematiche.
Spero di essere stato esauriente, e scusa per il giochetto di prima.
Se ho detto qualche m*****ata non torturatemi.:D

Trovo molto interessante la storia dell'origine dei pattern, che ignoravo e che riciclerò sicuramente :), ma la tua spiegazione mi ha convinto che non ci sono analogie significative tra sviluppo software e edilizia. Almeno non più che tra il software e qualsiasi prodotto della tecnologia umana.
Sulla carta il software è simile a un palazzo: è una roba che prima progetti, poi assembli, poi testi poi vendi e incroci le dita sperando che non si distrugga da solo negli anni a venire.
Ma lo stesso si può dire, per esempio, di qualsiasi cosa che esca da una catena di montaggio, da uno spazzolino elettrico ad un 747.
Anche un falegname che vuole costruire una sedia ne fa prima un disegnino sulla carta, poi ne assembla le parti da solo o in collaborazione con altri falegnami ( o anche professionalità diverse, es. se la spalliera è in ferro servirà un saldatore che lo lavori ) e alla fine ci si siede sopra una mezz'oretta e se non si ritrova improvvisamente con le chiappe per terra, aggiorna il numero di versione e va in gold :)

Scusa la tua risposta non ha senso con la mia domanda, almeno in italiano.

Si', lo ha. Rileggi con piu' attenzione.

L'hai messa tu sul personale chiedendomi se sono stato DIRETTAMENTE partecipe di una esperienza ti ricordo

E' una domanda del tutto lecita alla quale evidentemente non vuoi rispondere, ma ho capito che ti interessa solo cercare la rissa come al solito, quindi continua pure la tua polemichina da solo.
Ne parlo con gli altri.

Vorrei che l'articolista mi spiegasse la frase:
"Certo, riconosco che il discorso può non essere del tutto chiaro, così come ammetto il mio imbarazzo unito a soggezione quando mi sono trovato a dover intervistare Mr. Jacobson. Un conto è intervistare personaggi legati al mondo IT in genere, un altro è il mondo della programmazione"

Ma "il mondo della programmazione" è il cuore del mirabolante mondo dell'IT. Forse ci si dimentica che senza il firmware neppure il very very cool IPOD non va ed un firmware è (mirabile dictu) proprio un programma!

Capisco che siamo lontani dai tempi del mio vecchio Apple2, ma come si fa a scrivere di tecnologia ed informatica scevri dalla minima sensibilità su come un qualunque "pezzo tecnologico" sia costruito?

E che nessuno salti fuori con paragoni tipo "il programmatore è il muratore, il manager it è l'architetto, sono cose diverse", semplicemente perchè esempi del genere dimostrano spocchiosamente che nel mondo di oggi il "senso comune" considera validi architetti che non conoscono le tecniche di carpenteria. Peccato che da questi veri archi-asini vengano poi fuori mostri tipo ponti di calatrava.

Inoltre il CO-inventore di UML (non inventore, vi siete dimenticati di un certo Booch e di unacerta Rational) è un noto animale da conferenza, spesso abile inventore di fuffa, benchè dal lato della progettazione del software abbia dato valido contributo.

Ah, peraltro qui di programmazione non si parla neppure. Si parla di project management.

Oh tempora....Oh mores...

Mi suona strano vedere come nessuno qui abbia parlato nell'approccio che spesso un "neolaureato" si ritrova ad avere col mondo del lavoro. Posso raccontare la mia esperienza: assunto in una grande azienda di consulenza, armato dei miei buoni propositi, del mio KISS, del DRY, lyskov, etc etc, e trepidante in attesa di confrontarmi con metodologie di lavoro a me nuove tipo TDD o SCRUM, mi sono trovato tristemente a disagio: sono stato assegnato ad un team di sviluppo che lavora ad un'applicazione implementata veramente con i piedi e che segue una metodologia di sviluppo che definire "ad cazzum" è fare un complimento (roba che lavoravo meglio io da solo quando ho realizzato con contratto a progetto un sistema informativo per un'aziendina di Milano). Orari di lavoro indecenti, scadenze pressanti e nessun interesse per la qualità, solo la quantità: all'atto pratico, se devo fare un confronto con il periodo universitario, quando avevo tempo per studiare sperimentare e sviluppare, visto la pochezza delle problematiche affrontate e i metodi di lavoro scandalosi (sembra quasi che ti obblighino a produrre schifezza) credo di essere peggiorato in 6 mesi di lavoro. Ma la colpa di chi è se per fare software assumono anche gente del DAMS multimediale? Poi si lamentano che i neolaureati non hanno conoscenze sufficienti...

Mi suona strano vedere come nessuno qui abbia parlato nell'approccio che spesso un "neolaureato" si ritrova ad avere col mondo del lavoro. Posso raccontare la mia esperienza: assunto in una grande azienda di consulenza, armato dei miei buoni propositi, del mio KISS, del DRY, lyskov, etc etc, e trepidante in attesa di confrontarmi con metodologie di lavoro a me nuove tipo TDD o SCRUM, mi sono trovato tristemente a disagio: sono stato assegnato ad un team di sviluppo che lavora ad un'applicazione implementata veramente con i piedi e che segue una metodologia di sviluppo che definire "ad cazzum" è fare un complimento (roba che lavoravo meglio io da solo quando ho realizzato con contratto a progetto un sistema informativo per un'aziendina di Milano). Orari di lavoro indecenti, scadenze pressanti e nessun interesse per la qualità, solo la quantità: all'atto pratico, se devo fare un confronto con il periodo universitario, quando avevo tempo per studiare sperimentare e sviluppare, visto la pochezza delle problematiche affrontate e i metodi di lavoro scandalosi (sembra quasi che ti obblighino a produrre schifezza) credo di essere peggiorato in 6 mesi di lavoro. Ma la colpa di chi è se per fare software assumono anche gente del DAMS multimediale? Poi si lamentano che i neolaureati non hanno conoscenze sufficienti...

Cambia datore di lavoro. Parlo per esperienza personale.
I primi due anni di lavoro buttati nel cesso per quanto mi riguarda.
Fortuna che contemporaneamente sono riuscito a leggere tanto, rendendo quel periodo professionale comunque produttivo.
L'unica nota positiva è che so per esperienza diretta come NON si deve lavorare...

E' una domanda del tutto lecita alla quale evidentemente non vuoi rispondere, ma ho capito che ti interessa solo cercare la rissa come al solito, quindi continua pure la tua polemichina da solo.
Ne parlo con gli altri.
In realtà ti ho risposto portandoti ben due esempi.
Evidentemente non hai colto oppure sei troppo chiuso nelle tue convinzioni.

Riguardo l'intervista a Jacobson non aggiunge nulla al normale buon senso.

Riguardo la discussione carriera / ruoli: i neo laureati prima fanno i programmatori, poi mano mano salgono di ruolo: team leader, programme manager, dirigenti. Ovviamente dato che non tutti possono essere team leader o programme manager, qualcuno rimane indietro.... a meno che l'azienda si espande e assume nuovi neo. In questo caso i vecchi possono salire di ruolo piu' facilmente.
Nella mia azienda siamo quasi tutti laureati, e dato che facciamo software, qualcuno deve pur scriverlo... quindi tutti quanti abbiamo fatto / facciamo codice.

Riguardo il processo di sviluppo: noi lavoriamo per l'ESA e lo sviluppo e' sempre a cascata: requisiti, poi architettura / design / poi sviluppo & test e delivery. Ad ogni fase sono associate milestones con relativi pagamenti. Non si va' avanti se la milestone "is not achieved".

L'approccio waterfall funziona: anzi e' l'unico possibile per noi: il cliente ci chiede un sistema chiavi in mano per fare certe cose, non sono necessarie iterazioni. Succede spesso che splittiamo lo sviluppo in varie delivery per problemi di schedule: dato che andiamo lunghi allora prima gli diamo le funzioni con maggior priorita' (senno' ci cacciano :-) ) e poi le altre.

La separazione fra "software engineer" & developers non esiste per molti anni di carriera: la stessa persona puo' fare l'analisi, il design, il coding, testing.. dipende dalla fase del progetto e da quanto e' grande il progetto. In piccoli progetti il project leader puo' fare tutto, in grandi progetti si ferma all'architettura e poi fa la review dei documenti fatti dagli altri, coordinamento etc.
Io al momento sono Project Leader di un progetto di medie dimensioni e dato che siamo alla stretta finale, sto sviluppando pure io.

Ciao

Penso che l'iter di carriera nello sviluppo del SW che molti enunciano sia solo un iter di "necessità", vuoi perchè i soldi sono sempre pochi per i "peones" e vuoi perchè è l'unico modo per i datori di lavoro di premiare chi ha più capacità o semplicemente chi vuole assumersi più responsabilità.

Però penso che se una persona programma per anni, sicuramente quando dovrà prendere in mano una mansione in cui non si programma ma si creano e modificano specifiche non sarà al top della performance: sarà sempre e comunque legato alla forma mentis datagli da anni ed anni di programmazione.

Invece quello che mi sembra una buona idea è che in qualche azienda vedo una nuova figura professionale che è la persona che invece segue le specifiche come ruolo primario anche se rispetto alla programmazione non è certamente un completo ignorante. Sul coding ha una conoscenza secondaria, questo non vuol dire che non è capace, semplicemente vuol dire che non è il suo ruolo principale.

Effettivamente non mi sono accorto che le aziende che ho citato non sono propriamente prodduttori di software consumer, più che altro fanno middleware o software per automazione o per la gestione di hardware per i più svariati scopi, dove può essere che la specifica conti di più del codice...

Però penso che se una persona programma per anni, sicuramente quando dovrà prendere in mano una mansione in cui non si programma ma si creano e modificano specifiche non sarà al top della performance: sarà sempre e comunque legato alla forma mentis datagli da anni ed anni di programmazione.

Invece quello che mi sembra una buona idea è che in qualche azienda vedo una nuova figura professionale che è la persona che invece segue le specifiche come ruolo primario anche se rispetto alla programmazione non è certamente un completo ignorante. Sul coding ha una conoscenza secondaria, questo non vuol dire che non è capace, semplicemente vuol dire che non è il suo ruolo principale.


Intanto, la forma mentis del programmatore (ma uno serio, non tipo commerciale che usa vbasic per fare il figo) è la migliore risorsa che tu possa applicare a QUALSIASI tipo di lavoro. Questo perchè la programmazione è problema solving allo stato puro, è ricerca e sviluppo applicata su base giornaliera. Richiede inventiva, un pizzico di arte di arrangiarsi, un aggiornamento costante alle nuove tecnologie e oggi, a differenza del passato, anche una attenzione maggiore a metodologie più rigorose di verifica del codice, documentazione eccetera.
Poi qua si dimentica che, in un team di sviluppo, tra chi comanda e lo stuolo di poveri prog legati alla catena di montaggio esistono vari lead tecnici di livello più alto che, a mio modo di vedere, sono i candidati più naturali per qualsiasi posizione nell'ambito del middle management e anche di più.