Ivar Jacobson: ecco cosa non insegnano ai programmatori

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.

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.

DP GOF? Vediamo se la capisci...

ma dai!!!

Ma sei proprio te? cioè... davvero?
Anche qua?

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 :-)

Linguaggio inutile.



"Il" volevi dire?


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



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.

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?


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

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!

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.



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