Ivar Jacobson: ecco cosa non insegnano ai programmatori

[giogts]

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?

[cracovia]

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...

[Hador]

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".

[Big Bamboo]

Originariamente inviato da ReaToMe

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

[Gnubbolo]

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 ?

[PantWeb]

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.

[ottoking]

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

[Hador]

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

[frankie]

Originariamente inviato da skorpyo

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

e quindi neanche tanto nuove.

[Joker84]

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....

[ReaToMe]

Originariamente inviato da Big Bamboo

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

Di dove sei?

[supersalam]

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ù?

[ReaToMe]

Originariamente inviato da PantWeb

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?

[ReaToMe]

Originariamente inviato da supersalam

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.

[Dreadnought]

Originariamente inviato da supersalam

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.

[ReaToMe]

Originariamente inviato da Dreadnought

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.

[Arthens]

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.

[MesserWolf]

Originariamente inviato da Dreadnought

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

[jeremy.83]

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

[Rock Elite]

un grazie al dottor jacobson e a voi di hwupgrade