Ivar Jacobson: ecco cosa non insegnano ai programmatori

[WarDuck]

Originariamente inviato da pabloski

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

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.

[Dreadnought]

Originariamente inviato da LMCH

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.

[Marziano]

Originariamente inviato da Dreadnought

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?

Originariamente inviato da Dreadnought

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?

Originariamente inviato da Dreadnought

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.

[Dreadnought]

Originariamente inviato da Marziano

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

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

[NWEvolution]

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.

[nicolad1988]

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

[Marziano]

Originariamente inviato da Dreadnought

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.

Originariamente inviato da Dreadnought

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.

Originariamente inviato da Dreadnought

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?

Originariamente inviato da Dreadnought

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

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

Originariamente inviato da Dreadnought

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.

[Marziano]

post duplicato, sorry

[ConteZero]

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.

[fek]

Originariamente inviato da Dreadnought

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?

[AlexAlex]

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

[AlexAlex]

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.

[fek]

Originariamente inviato da AlexAlex

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.

[ReaToMe]

Originariamente inviato da Marziano

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

DP GOF? Vediamo se la capisci...

[pgb]

Originariamente inviato da ConteZero

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?
Anche qua?

PGB

[AlexAlex]

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

[waccos]

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

[islandofjava]

Originariamente inviato da lowenz

Ecco quello che ha creato l'UML

Te possino....

Linguaggio inutile.

Originariamente inviato da lowenz

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



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.

[Dreadnought]

Originariamente inviato da fek

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

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?

[SwatMaster]

Questo si che è un homo novus!