Ivar Jacobson: ecco cosa non insegnano ai programmatori

[Redazione di Hardware Upg]

Link all'Articolo: http://www.hwupgrade.it/articoli/sof...ori_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.

[zarko]

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

[Hador]

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)

[Helldron]

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.

[Dominioincontrastato]

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

[ottoking]

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

Originariamente inviato da Dominioincontrastato

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

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?

Originariamente inviato da ottoking

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?

[ReaToMe]

Originariamente inviato da ottoking

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

[GlobuS]

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

[lowenz]

Ecco quello che ha creato l'UML

Te possino....

[lowenz]

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

[NIC78]

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

[Caleb The Game]

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

[sirus]

Originariamente inviato da lowenz

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.

[sirus]

Originariamente inviato da Caleb The Game

(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

[ReaToMe]

Originariamente inviato da Caleb The Game

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.

[WarSide]

Originariamente inviato da ottoking

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?

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

[skorpyo]

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

[ReaToMe]

Originariamente inviato da WarSide

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

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.

Originariamente inviato da WarSide

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

Originariamente inviato da WarSide

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

Originariamente inviato da WarSide

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

Originariamente inviato da WarSide

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

Originariamente inviato da WarSide

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

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