Pwn2Own, Chrome si mette alla prova

centro
Cassandra, anche stavolta hai centrato il problema. La burocrazia ci soffoca, e chi ha idee (aka progetti) ma nessun santo in paradiso si deve arrendere. Ancora per poco?

Re: centro
- Scritto da: gioca90> Cassandra, anche stavolta hai centrato il> problema. La burocrazia ci soffoca, e chi ha idee> (aka progetti) ma nessun santo in paradiso si> deve arrendere. Ancora per> poco?Perché poi cosa succede? Vai all'estero? ;)Perché se pensi che via il nano le cose possano volgere al meglio si vede che non hai ben chiara la storia di questa repubblica...Purtroppo lo stato italiano è totalmente in cancrena e l'unica soluzione è l'amputazione di tutti i suoi organi!

Re: centro
no, non vado all'estero e non credo che "via il nano via i problemi". Anzi, quando andra' via forse ci accorgeremo che per anni non abbiamo fatto altro che accendere i riflettori sempre nello stesso posto, perdendo di vista gli altri problemi, altrettanto seri.Se avessi 20 anni di meno, comunque, emigrerei :)

Re: centro
parole sante.se pensate che i veri problemi id cui dovrebbe occuparsi la gente siano quelle razzate di ruby & c. vedrete quando i riflettori si sposteranno dal nano e illumineranno tutte le altre cose ignorate per una caccia alle streghe...

Re: centro
da quotare integralmente.

gli obiettivi dichiarati non son quelli
Caro Calamari, lo vedo tutti i giorni: gli obiettivi dichiarati non corrispondo agli obiettivi reali. Non solo nel pubblico, anche nel privato.I veri obiettivi nel mondo del lavoro sono tre:1) coltivare il proprio orto di potere2) fare più soldi possibile nel minor tempo possibile3) salvarsi le chiappe facendo 1 e 2.Quando un progetto fallisce questi tre punti sono sempre nella parte alta delle priorità di qualcuno. E quel qualcuno, di solito, non è l'addetto alle pulizie.

Re: gli obiettivi dichiarati non son quelli
parole sante!

Colpiti ed affondati...
Dove comandano gli incapaci i risultati sono pessimi... in Italia i governanti degli ultimi 20 anni hanno affondato la meritocrazia sostituendola con mignottocrazia e (quando va bene) calcinculandia ! Vedere che posti occupano ( e con quali stipendi) gente come la Minetti e la Carfagna fa passare qualsiasi voglia di impegno anche al più volenteroso degli onesti !

Re: Colpiti ed affondati...
perche secondo te 30 o 40 anni fa c'era meritocrazia? l'italia è la patria della raccomandazione, find dai tempi dell'impero romano

Obiettivi nulli?
Il fatto che i soldi siano stati spesi e fossero pubblici (cioè di nessuno) dovrebbe suggerire che gli obiettivi ci fossero e siano stati tutti perfettamente centrati.

Re: Obiettivi nulli?
Purtroppo

Contro domanda (maieutica)
Come mai per costruire un grattacielo occorre assegnare il progetto ad un professionista, mentre per progettare una struttura informatica no?

Re: Contro domanda (maieutica)
Perché tanto è una XXXXXXXta, lo fai col computer due click e sei pronto, cosa ci sarà mai di difficile?Se lo sapevo Italia.it glielo facevo io in 15 minuti con iWeb

Re: Contro domanda (maieutica)
- Scritto da: Andrea S> Perché tanto è una XXXXXXXta, lo fai col computer> due click e sei pronto, cosa ci sarà mai di> difficile?> Se lo sapevo Italia.it glielo facevo io in 15> minuti con> iWebMio cuggino lo faceva per 30 euro...

Re: Contro domanda (maieutica)
Ero ironico...

Re: Contro domanda (maieutica)
- Scritto da: HappyCactus> Come mai per costruire un grattacielo occorre> assegnare il progetto ad un professionista,> mentre per progettare una struttura informatica> no?da professionista del settore, ti dico che stai sbagliando bersaglio...il punto non è se a progettare sono dei professionisti... e peraltro le più grandi e peggiori porcherie sono progettate proprio da professionisti...

Re: Contro domanda (maieutica)
- Scritto da: che pena> da professionista del settore, ti dico che staiQuale settore, per specificare. ICT oppure di progettazione (cioè sei un ingegnere edile/civile, architetto, ecc...?)> sbagliando> bersaglio...> > il punto non è se a progettare sono dei> professionisti... Per "professionista" intendo una persona o società di persone che a) si occupano esclusivamente di progettazione (e non di realizzazione!) di sistemi informatici, b) applicano rigorosi criteri di ideazione, gestione e supervisione del progetto, c) concorrono a rispondere della mancata rispondenza del progetto ai requisiti rigorosamente stabiliti in partenza, d) rispondono al criterio di TERZIETA' rispetto il committente e chi realizza il progetto. > e peraltro le più grandi e> peggiori porcherie sono progettate proprio da> professionisti...Questa è una presa di posizione aprioristica, forte purtroppo del fatto che in Italia spesso non vi sono i criteri sopra proposti, tuttavia poco rispondente alla realtà dei fatti.

Re: Contro domanda (maieutica)
Il problem è proprio questo. Il fatto che si pensi che la progettazione di un software sia paragonabile alla costruzione di una casa. Il fallimento di tantissimi progetti dimostra che non è affatto così. Anzi prendere tuttle le decisioni a priori è la ricetta per il sicuro fallimento. Ci sono fior di libri di ingengeria del software che ripetono questo concetto.Il fatto che poi a prendere le decisioni siano manager che hanno poca o nulla esperienza nella gestione un progetto sw sicuramnte non migliora la situazione.Se ci aggiungi il regolare magna-magna hai fatto tombola.

Re: Contro domanda (maieutica)
Perchè tutti hanno un computer, una macchina fotografica, una videocamera.Con cui sono in grado di sfornare prodotti "bassamente professionali".Invece pochi hanno un'impresa edile.

my 2 cents
Ho notato, anche nel privato, che spesso ci si focalizza solamente sull'obiettivo considerando secondario il mezzo attraverso il quale conseguire l'obiettivo. E questo porta alle solenni cantonate che abbiamo visto. Ricordo, circa 10 anni fa, che molti volevano lanciarsi nell'ecommerce ma tanti fra questi pensavano solo ad avere un sito luccicante con flash ed effetti stroboscopici ma non si fermavano un attimo a riflettere su cosa vendere, a chi e come gestire la logistica degli approvvigionamenti e della consegna della merce. Cercando soluzioni tanto immediate quanto campate per aria quando arrivavano le rogne, ovviamente molti dei progetti si risolvevano in paurosi buchi nell'acqua e buchi nel portafoglio dell'avventato di turno. Per i progetti italiani credo sia capitata la stessa cosa, si è pensato solamente agli obiettivi da raggiungere senza pensare al modo di perseguirli, e questo ha causato, eufemisticamente parlando, qualche piccolo problemuccio...

Re: my 2 cents
- Scritto da: shevathas> [...]> Per i progetti italiani credo sia capitata la> stessa cosa, si è pensato solamente agli> obiettivi da raggiungere senza pensare al modo di> perseguirli, e questo ha causato,> eufemisticamente parlando, qualche piccolo> problemuccio...uhm... no...il punto centrale è che:- gli obiettivi da raggiungere per chi ha in mano le carte vincenti del gioco sono in realtà solo uno, facilissimo da definire e chiarissimo: il saccheggio dei finanziamenti - e questi "soggetti" hanno dimostrato, e dimostrano, di conoscere benissimo il modo di raggiungere l'obiettivo e di reiterarlo nei decenni...il tutto, ovviamente, alla faccia tua e mia

alcuni motivi del disastro...
Anch'io ho una certa qual esperienza del tipo di progetti citati nell'articolo. IMHO:1. si sopravvaluta troppo la fase progettuale: sono tutti progettisti raffinati e nessuno sa scrivere codice. Si spende tempo e denaro in complicati documenti pieni di UML e compagnia bella, ma il committente non e' in grado di capirli e approva cose di cui non si rende conto appieno2. nessuno, neanche gli Einstein della progettazione, sono in grado di prevedere con precisione le funzionalita' che il sistema dovra' avere davvero. Ci si puo' avvicinare, ma solo quando il committente comincia ad usare il prodotto si rendera' conto di cosa manca e di cosa invece c'e' ma non serve a nulla. Chi crede che si possa prevedere e i bravi ci riescono e' un illuso. L'unico modo di sviluppare sistemi funzionanti e' la "beta permanente": si fa una demo funzionante delle cose fondamentali nel giro di poche settimane, si fa vedere agli utenti e via via si aggiusta aggiungendo e correggendo le funzionalita' fino ad avere tutte e solo le funzioni necessarie. Un po' alla volta si costruisce il sistema in modo incrementale.3. quando i tempi totali di sviluppo superano i sei mesi/un anno si corre il serio rischio che le necessita' nel frattempo cambino, che i responsabili cambino, ecc. ecc. per cui se si vuole evitare la catastrofe e' fondamentale che il primo collaudo avvenga entro questo arco temporale4. gli sviluppi vengono fatti fare ai soliti giovanissimi nelaureati da 800 euro/mese attraverso una catena interminabile di subappalti: la qualita' del codice e' infima, le scelte architetturali ingenue (per una form di memorizzazione sul database da erogarsi a milioni di pagine al giorno si usano piattaforme java con catene di ereditarieta' infinite, quando un aspx o un php sarebbe due ordini di grandezza piu' performante e piu' corto da scrivere; Italia.it lo scrivono con Joomla e poi si meravigliano che non regge la botta degli accessi..ecc. ecc.)5. la catena infinita che dal primo vincitore della gara porta all'ultimo livello dei peones che veramente sviluppano obbliga a costi spaventosi, tutti devono fare un bel markup e poi con i soldi che restano ci si deve accontentare del programmatorino che l'unico programma che ha scritto prima e' la rubrica telefonica personale (e che neanche funziona)Per concludere: ho avuto qualche volta la netta sensazione che qualche societa' di consulenza di quelle davvero grosse sfrutti a proprio vantaggio questa situazione appositamente progetti sistemi software enormi che non potranno andare in esercizio. A quel punto non sviluppano proprio il sistema, oppure fanno finta mettendo insieme un po' di codice non funzionante e non testato, tanto non entrera' mai in esercizio e loro risparmiano tutti i costi di sviluppo.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> scelte architetturali ingenue (per una form di> memorizzazione sul database da erogarsi a milioni> di pagine al giorno si usano piattaforme java con> catene di ereditarieta' infinite, quando un aspx> o un php sarebbe due ordini di grandezza piu'> performante e piu' corto da scrivere; Italia.it> lo scrivono con Joomla e poi si meravigliano che> non regge la botta degli accessi..ecc.> ecc.)Da dove esce questo italia.it fatto con Joomla!?

Re: alcuni motivi del disastro...
> Da dove esce questo italia.it fatto con Joomla!?Dai era un esempio, non mi ricordo con cosa fosse fatto il primo italia.it ma era un accrocchio di due cose diverse di cui uno era un cms open source. e' passato un po' di tempo, ed io l'ho visto prima che fosse aperto al pubblico ;-)

Re: alcuni motivi del disastro...
- Scritto da: ciliani> > Da dove esce questo italia.it fatto con Joomla!?> Dai era un esempio, non mi ricordo con cosa fosse> fatto il primo italia.it ma era un accrocchio di> due cose diverse di cui uno era un cms open> source. e' passato un po' di tempo, ed io l'ho> visto prima che fosse aperto al pubblico> ;-)Pensavo lo avessero adottato davvero.Non ci vedrei niente di male però: potrebbe essere usato un CMS per trovarsi alcuni elementi già pronti e rifare/ottimizzare/ignorare quello che non serve.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> Anch'io ho una certa qual esperienza del tipo di> progetti citati nell'articolo.> IMHO:> > 1. si sopravvaluta troppo la fase progettuale:> sono tutti progettisti raffinati e nessuno sa> scrivere codice. Scrivere codice non è progettare, così come metter mattoni non è progettare un edificio.Credo invece che la progettazione sia considerato un optional inutile, in informatica.>Si spende tempo e denaro in> complicati documenti pieni di UML e compagnia> bella, ma il committente non e' in grado di> capirli e approva cose di cui non si rende conto> appienoNon è compito suo approvarli. Per comprare casa hai per caso approvato i calcoli strutturali?> 2. nessuno, neanche gli Einstein della> progettazione, sono in grado di prevedere con> precisione le funzionalita' che il sistema dovra'> avere davvero. E le specifiche funzionali a cosa servono?> Ci si puo' avvicinare, ma solo> quando il committente comincia ad usare il> prodotto si rendera' conto di cosa manca e di> cosa invece c'e' ma non serve a nulla. Significa che la progettazione è stata fatta male.> L'unico modo di sviluppare sistemi> funzionanti e' la "beta permanente": si fa una> demo funzionante delle cose fondamentali nel giro> di poche settimane, si fa vedere agli utenti eQuesto è un paradigma vagamente simile all'agile, ma all'italiana. Butto giù qualcosa e vediamo come va. E' il motivo per cui poi i costi si moltiplicano, tanto nel pubblico qualcuno pagherà.> 4. gli sviluppi vengono fatti fare ai soliti> giovanissimi nelaureati da 800 euro/mese> attraverso una catena interminabile di> subappalti: la qualita' del codice e' infima, leScrivere codice non è progettare.> 5. la catena infinita che dal primo vincitore> della gara porta all'ultimo livello dei peones> che veramente sviluppano obbliga a costi> spaventosi, tutti devono fare un bel markup e poi> con i soldi che restano ci si deve accontentare> del programmatorino che l'unico programma che ha> scritto prima e' la rubrica telefonica personale> (e che neanche> funziona)> Perché scrivere codice non è progettare (e tre.)> Per concludere: ho avuto qualche volta la netta> sensazione che qualche societa' di consulenza di> quelle davvero grosse sfrutti a proprio vantaggio> questa situazione appositamente progetti sistemi> software enormi che non potranno andare in> esercizio. A quel punto non sviluppano proprio il> sistema, oppure fanno finta mettendo insieme un> po' di codice non funzionante e non testato,> tanto non entrera' mai in esercizio e loro> risparmiano tutti i costi di> sviluppo.Questo è semplicemente perché non c'è responsabilità, men che meno nel pubblico. Se una cosa non funziona è perché è colpa di qualcun altro.All'estero infatti, dove chi non lavora bene ne risponde con cause milionarie, la progettazione si fa dall'inizio, e chi scrive il codice non è chi progetta.

Re: alcuni motivi del disastro...
> E le specifiche funzionali a cosa servono?Non puoi buttare giu' le specifiche di una cosa che nessuno sa con precisione cosa deve fare. Tu presumi di essere in grado di saperlo, ma e' una battaglia persa: nessuno e' in grado di saperlo.> Significa che la progettazione è stata fatta male.Leggo spesso su questo forum gli interventi dei super esperti. Beato tu che sai fare la progettazione bene. Scommetto che sono sul mercato da almeno vent'anni piu' di te ed ho diretto progetti di sviluppo molto maggiori dei tuoi, ma pazienza. Non volevo entrare nel tecnico e nel filosofico ma questi sono temi dibattuti in maniera approfondita anche all'estero, e sono temi attuali di software engineering. Dubito che basti essere "un po' piu' bravi" per assicurare che i progetti software non falliscano. Capisco che sono passati molti anni dal "mythical man month" ma le soluzioni definitive non sono ancora state trovate. Ma forse tu mi puoi correggere.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> > E le specifiche funzionali a cosa servono?> Non puoi buttare giu' le specifiche di una cosa> che nessuno sa con precisione cosa deve fare. Tu> presumi di essere in grado di saperlo, ma e' una> battaglia persa: nessuno e' in grado di> saperlo.Questa è una presa di posizione errata di principio.Se non sai a cosa serve (non che cosa deve far!) è inutile farla.Se sai a cosa serve, sai cosa deve fare. E da questo puoi immaginare come deve farlo.Ovviamente non è una condizione statica - può nascere una esigenza -, tuttavia la progettazione fatta come si deve è in grado di rispondere a questa problematica.> > Significa che la progettazione è stata fatta> male.> > Leggo spesso su questo forum gli interventi dei> super esperti. Beato tu che sai fare la> progettazione bene. Scommetto che sono sul> mercato da almeno vent'anni piu' di te ed ho> diretto progetti di sviluppo molto maggiori dei> tuoi, ma pazienza. Potrei dire lo stesso. E quindi?> Non volevo entrare nel tecnico> e nel filosofico ma questi sono temi dibattuti in> maniera approfondita anche all'estero, e sono> temi attuali di software engineering. Infatti, anni di teoria e studio sull'ingegneria, e sull'ingegneria del software nello specifico buttati nel XXXXX perché "non si può sapere a priori cosa deve fare un sistema". Balle. Il problema non è che non si sa cosa dovrà fare un sistema, ma come fare, date le specifiche di oggi, a progettare (di nuovo questa parola!) il sistema in modo da renderlo flessibile a successive evoluzioni.Questa necessità porta, a seconda di quanto oggi sono noti i requisiti, ad approcci "agili" (che non sono la filosofia del faccio qualcosa a caso da te proposta) oppure ad altri più rigidi.Ma di base c'è sempre progettazione.> Dubito che> basti essere "un po' piu' bravi" per assicurare> che i progetti software non falliscano. Mai pensato questo, non so da dove tu l'abbia tirato fuori.> Capisco> che sono passati molti anni dal "mythical man> month" ma le soluzioni definitive non sono ancora> state trovate. Ma forse tu mi puoi> correggere.E chi ha parlato di soluzioni definitive? Dico solo che liquidare tutto con "la progettazione è impossibile" è una fesseria. E' un modo per giustificare l'approccio "a XXXXX" tipico dei progetti IT citati dall'articolo.

Re: alcuni motivi del disastro...
Mi spiace contraddirti, ma una progettazione accurata in campo informatico non da nessuna certezza sul sucXXXXX o sul fallimento di un progetto. Tanto tanto più si progetta a lungo termine, tanto più le previsioni si possono rivelare errate.La progettazione deve essere essenziale e comprensibile e se chi programma sa fare il suo mestiere non è necessario specificare ogni minimo particolare.E come sempre: "no silver bullet!"

Re: alcuni motivi del disastro...
- Scritto da: Ichigo> Mi spiace contraddirti, ma una progettazione> accurata in campo informatico non da nessuna> certezza sul sucXXXXX o sul fallimento di un> progetto.Non mi stai affatto contraddicendo, leggi quanto detto. Un buon prodotto (informatico, elettronico o gastronomico) non è un prodotto bellissimo, è un prodotto che si vende, che è redditizio. Questo determina il sucXXXXX o fallimento di un progetto. Intendendo, per estensione, con "redditizio" nel senso del valore anche funzionale - come nel caso di Italia.it.Ma questo è vero non solo per il settore informatico, come detto! > Tanto tanto più si progetta a lungo termine,> tanto più le previsioni si possono rivelare> errate.> La progettazione deve essere essenziale e> comprensibile e se chi programma sa fare il suo> mestiere non è necessario specificare ogni minimo> particolare.> E come sempre: "no silver bullet!"Programmare non è progettare (e quattro!)Scrivere codice non è progettare! Scrivere codice è manovalanza, che deve rispettare certi criteri - leggibilità, riusabilità, aderenza alle specifiche, eccetera - ma pur sempre manovalanza! Certo se il codice è scritto con i piedi gli effetti si vedono - come un muratore che tira su il muro storto - ed infatti nello sviluppo di un progetto complesso come un progetto software non c'è solo la progettazione, c'è anche la direzione lavori, l'esecuzione, il collaudo, la QA e via discorrendo. Tutte cose che ahimè anche in questa discussione vedo snobbata parlando di "interminabile catena burocratica"...E più il progetto è a lungo termine (relativamente parlando, dipende dal settore di applicazione), più questi passaggi devono essere curati.

Re: alcuni motivi del disastro...
> Scrivere codice non è progettare, così come> metter mattoni non è progettare un> edificio.> Credo invece che la progettazione sia considerato> un optional inutile, in> informatica.Ecco il più grande errore della storia dell'informatica. Essendo una disciplina relativamente giovane si è cercato di adattare il paradigma delle altre ingegnerie tradizionali e si è detto:Progettista = ArchitettoProgrammatore = MuratoreChe è una cosa che non ha funzionato e che non sta ne in cielo ne in terra. L'analisi e la progettazione sicuramente ci vogliono, ma sono soggette a continui cambiamenti in corso d'opera e non devono essere delle fasi a "tenuta stagna" rispetto allo sviluppo, come invece si vuole far credere e come spesso insegnano i professori universitari, che magari non sono mai usciti dall'università.Il progettista e lo sviluppatore devono lavorare sempre a fianco e, spesso, alcuni di loro sono entrambe le cose.

Re: alcuni motivi del disastro...
- Scritto da: Enterprise Profession al> Il progettista e lo sviluppatore devono lavorare> sempre a fianco e, spesso, alcuni di loro sono> entrambe le> cose.Ho detto qualcosa di diverso?E' una questione di ambiti. Si è abituati a pensare, e molte risposte qui lo confermano, che deve essere chi scrive codice a progettare, ma non è così. Sono ambiti diversi.Può anche essere che chi progetta scriva anche codice, e magari, sia anche il committente e/o il responsabile del progetto, perché no? ma, permettimi, sono ambiti diversi, in cui ciascuno deve "svestirsi" di un ruolo (per esempio del programmatore) quando serve un ruolo diverso (per esempio, dell'analista o del domain expert, o del project manager).

Re: alcuni motivi del disastro...
> Ecco il più grande errore della storia> dell'informatica. Essendo una disciplina> relativamente giovane si è cercato di adattare il> paradigma delle altre ingegnerie tradizionali e> si è> detto:> > Progettista = Architetto> Programmatore = Muratore> > Che è una cosa che non ha funzionato e che non> sta ne in cielo ne in terra. dissento.> L'analisi e la> progettazione sicuramente ci vogliono, ma sono> soggette a continui cambiamenti in corso d'opera> e non devono essere delle fasi a "tenuta stagna"> rispetto allo sviluppo, come invece si vuole far> credere e come spesso insegnano i professori> universitari, che magari non sono mai usciti> dall'università.allora il waterfall come tecnica di progettazione è stata mollata, come paradigma unico di progettazione, alla fine degli anni '80 almeno. Al giorno d'oggi ci sono diverse tecniche per l'ingegnerizzazione del software e sta all'architetto del sistema scegliere le più appropriate sulla base delle esigenze del committente. Spesso chi polemizza contro la progettazione e l'ingegnerizzazione del progetto pensa spesso ad applicazioni semplici che possono essere seguite facilmente da una sola persona, ovvero una sola persona si occupa sia dell'analisi che della realizzazione.> > Il progettista e lo sviluppatore devono lavorare> sempre a fianco e, spesso, alcuni di loro sono> entrambe le> cose.nei progetti piccoli. In quelli medi e grossi è il progettista che da le specifiche agli sviluppatori. Ovviamente anche il progettista deve avere competenze sullo sviluppo, così da sapere cosa sta chiedendo.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> Anch'io ho una certa qual esperienza del tipo di> progetti citati nell'articolo.> IMHO:> > 1. si sopravvaluta troppo la fase progettuale:> sono tutti progettisti raffinati e nessuno sa> scrivere codice. Si spende tempo e denaro in> complicati documenti pieni di UML e compagnia> bella, ma il committente non e' in grado di> capirli e approva cose di cui non si rende conto> appieno> > 2. nessuno, neanche gli Einstein della> progettazione, sono in grado di prevedere con> precisione le funzionalita' che il sistema dovra'> avere davvero. Ci si puo' avvicinare, ma solo> quando il committente comincia ad usare il> prodotto si rendera' conto di cosa manca e di> cosa invece c'e' ma non serve a nulla. Chi crede> che si possa prevedere e i bravi ci riescono e'> un illuso. L'unico modo di sviluppare sistemi> funzionanti e' la "beta permanente": si fa una> demo funzionante delle cose fondamentali nel giro> di poche settimane, si fa vedere agli utenti e> via via si aggiusta aggiungendo e correggendo le> funzionalita' fino ad avere tutte e solo le> funzioni necessarie. Un po' alla volta si> costruisce il sistema in modo> incrementale.> > 3. quando i tempi totali di sviluppo superano i> sei mesi/un anno si corre il serio rischio che le> necessita' nel frattempo cambino, che i> responsabili cambino, ecc. ecc. per cui se si> vuole evitare la catastrofe e' fondamentale che> il primo collaudo avvenga entro questo arco> temporale> > 4. gli sviluppi vengono fatti fare ai soliti> giovanissimi nelaureati da 800 euro/mese> attraverso una catena interminabile di> subappalti: la qualita' del codice e' infima, le> scelte architetturali ingenue (per una form di> memorizzazione sul database da erogarsi a milioni> di pagine al giorno si usano piattaforme java con> catene di ereditarieta' infinite, quando un aspx> o un php sarebbe due ordini di grandezza piu'> performante e piu' corto da scrivere; Italia.it> lo scrivono con Joomla e poi si meravigliano che> non regge la botta degli accessi..ecc.> ecc.)> > 5. la catena infinita che dal primo vincitore> della gara porta all'ultimo livello dei peones> che veramente sviluppano obbliga a costi> spaventosi, tutti devono fare un bel markup e poi> con i soldi che restano ci si deve accontentare> del programmatorino che l'unico programma che ha> scritto prima e' la rubrica telefonica personale> (e che neanche> funziona)> > Per concludere: ho avuto qualche volta la netta> sensazione che qualche societa' di consulenza di> quelle davvero grosse sfrutti a proprio vantaggio> questa situazione appositamente progetti sistemi> software enormi che non potranno andare in> esercizio. A quel punto non sviluppano proprio il> sistema, oppure fanno finta mettendo insieme un> po' di codice non funzionante e non testato,> tanto non entrera' mai in esercizio e loro> risparmiano tutti i costi di> sviluppo.Giacchè ci sei metti pure i nomi... qualcuno ha detto Accenture? Qualcun altro ha detto Engineering?e qualcun altro il "sommo appaltatore" e principale responsabile del "carrozzonismo ipertrofico" ovvero SOGEI?E si... manca ancora qualcuno... ma il metodo è chiaro!Sarebbe chiara anche la soluzione se l'obiettivo non è raggiunto si va a casa!Ma è una soluzione molto difficile perchè presuppone che venga meno la "pappatoria" per la zia il cognato il fratello e tutta la corte dei miracoli che poi alle elezioni da il voto "a chi di dovere".È un ottimo sistema si chiama MAFIA!

Re: alcuni motivi del disastro...
Sono d'accordo su tutto tranne che su questo.Fissati gli scopi di un progetto informatico un buon ingegnere deve riuscire a prevedere almeno l'80% di funzionalità e carichi applicativi e deve prevenire quelle che saranno le esigenze del committente.Altrimenti, davvero, è meglio affidare il tutto a neolaureati.La beta permanente è una follia.Un sito come Italia.it dovrebbe essere solido ed affidabile alla prima visita altrimenti non ce ne sarà una seconda ;)> 2. nessuno, neanche gli Einstein della> progettazione, sono in grado di prevedere con> precisione le funzionalita' che il sistema dovra'> avere davvero. Ci si puo' avvicinare, ma solo> quando il committente comincia ad usare il> prodotto si rendera' conto di cosa manca e di> cosa invece c'e' ma non serve a nulla. Chi crede> che si possa prevedere e i bravi ci riescono e'> un illuso. L'unico modo di sviluppare sistemi> funzionanti e' la "beta permanente": si fa una> demo funzionante delle cose fondamentali nel giro> di poche settimane, si fa vedere agli utenti e> via via si aggiusta aggiungendo e correggendo le> funzionalita' fino ad avere tutte e solo le> funzioni necessarie. Un po' alla volta si> costruisce il sistema in modo> incrementale.

Re: alcuni motivi del disastro...
- Scritto da: lui> Sono d'accordo su tutto tranne che su questo.> Fissati gli scopi di un progetto informatico un> buon ingegnere deve riuscire a prevedere almeno> l'80% di funzionalità e carichi applicativi e> deve prevenire quelle che saranno le esigenze del> committente.> Altrimenti, davvero, è meglio affidare il tutto a> neolaureati.> La beta permanente è una follia.> Un sito come Italia.it dovrebbe essere solido ed> affidabile alla prima visita altrimenti non ce ne> sarà una secondaHai ragione perfettamente. La beta permanente la dicevo per le cose complesse, e poi "permanente" fino ad un certo punto, diciamo per il primo anno di esercizio. L'80% sarebbe un bel traguardo, ma di certo hai ragione anche su questo, penso che una buona parte si possa capire fin dall'inizio. Molto dipende dagli interlocutori, capita anche sovente che un dirigente chieda un sistema che dovra' essere usato dai propri dipendenti senza aver chiaro cosa facciano i propri dipendenti. Quando poi capita che gli utilizzatori finali (opps) del sistema lo vedono per la prima volta al collaudo succede che si scopra che il sistema non fa quello che dovrebbe fare. Un dirigente in gamba ti permettera' di prevedere anche il 95% della applicazione, uno scarso invece... quando capisci di avere a che fare con un idiota e' meglio cominciare da subito a far vedere cose sul computer.Per un sito come Italia.it sono d'accordo con te, li' una analisi esaustiva si poteva fare molto semplicemente prima, e non c'era alcun problema serio di ingegneria software. Tra l'altro bastava dire "guarda france.fr o simili ed imitalo di sana pianta"

Re: alcuni motivi del disastro...
- Scritto da: ciliani> - Scritto da: lui> Molto dipende dagli interlocutori, capita anche> sovente che un dirigente chieda un sistema che> dovra' essere usato dai propri dipendenti senza> aver chiaro cosa facciano i propri dipendenti.> Quando poi capita che gli utilizzatori finali> (opps) del sistema lo vedono per la prima volta> al collaudo succede che si scopra che il sistema> non fa quello che dovrebbe fare. Un dirigente in> gamba ti permettera' di prevedere anche il 95%> della applicazione, uno scarso invece...Ma sei TU l'analista, e capire cosa vuole DAVVERO il cliente e non quello che pensa gli possa servire, fa parte del TUO lavoro, non del suo.> Per un sito come Italia.it sono d'accordo con te,> li' una analisi esaustiva si poteva fare molto> semplicemente prima, e non c'era alcun problema> serio di ingegneria software. Tra l'altro bastava> dire "guarda france.fr o simili ed imitalo di> sana> pianta"Naaaa te lo avrebbero fatto in francese ;)

Re: alcuni motivi del disastro...
Mi sono reso conto che forse ho dato l'impressione di affermare che la progettazione non serva. Quello che intendevo dire:1. la progettazione va fatta, sulla base di quello che chiede il committente. Il committente pero' si sbaglia (come dice House che i pazienti mentono..."i committenti si sbagliano. I committenti non sanno quello che vogliono")2. il committente deve validare la proposta. Ma non e' in grado di capire dai documenti che riceve se la proposta e' valida oppure no. Pensa di vedere nell'analisi cartacea funzioni che non ci sono, ecc. Eventuali diagrammi confondono piu' che chiarire.3. l'unico modo affinche' il committente abbia chiaro in che consiste la proposta e' vedere il prodotto finito in funzione. Solo allora si rende conto che ha chiesto cose errate.4. per questo e' bene presentare un prototipo quanto prima possibile. Vedendo il prototipo il committente capira' se ha chiesto le cose giuste e se non si e' dimenticato nulla. Inoltre forse fara' vedere il prototipo a qualcuno degli utenti finali veri, cosa che non succede in genere mai per il cartaceo della progettazione formale5. ovviamente non si puo' prototipare tutto un sistema complesso: si comincera' con le cose piu' importanti o le prime in ordine di proXXXXX.6. in genere al secondo, massimo al terzo prototipo le idee sono veramente chiare per poter stilare la progettazione definitiva7. da qui in poi tutto va come nel modo tradizionale. Bisogna pero' essere dotati di tool di sviluppo, team in gamba e correttamente dimensionato, ecc. perche' il collaudo non deve tardare piu' di sei mesi/un anno.Ogni passo dovrebbe essere vidimato dai responsabili... cosa che spesso e' impossibile, nel pubblico ci sono settori in cui chiunque si rifiuta di mettere anche una minima firmetta (siamo in Italia). Per questo e' buona cosa uno scambio di email, in cui ci si finge anche un po' cretini per reiterare per iscritto le cose che sono uscite negli incontri relativi ai prototipi

Re: alcuni motivi del disastro...
- Scritto da: ciliani> Ogni passo dovrebbe essere vidimato dai> responsabili... cosa che spesso e' impossibile,> nel pubblico ci sono settori in cui chiunque si> rifiuta di mettere anche una minima firmetta> (siamo in Italia). Per questo e' buona cosa uno> scambio di email, in cui ci si finge anche un po'> cretini per reiterare per iscritto le cose che> sono uscite negli incontri relativi ai> prototipiQuanta saggezza! ;)

Re: alcuni motivi del disastro...
QUOTONE

Re: alcuni motivi del disastro...
la progettazione va fatta, sulla base di> quello che chiede il committente. Il committente> pero' si sbaglia (come dice House che i pazienti> mentono..."i committenti si sbagliano. I> committenti non sanno quello che> vogliono")Purtroppo i committenti chiedono una cosa, ne vogliono un'altra (problema di sintassi)ed in realtà gliene serve un'altra ancora -che neanche immaginano- e che in futuro si lamenteranno di non avere.Su sistemi non troppo grandi io cerco di realizzare ciò che credo che gli servirà in futuro e lo nascondo.In tanti casi si è rivelata una strategia vincente anche da un punto di vista economico.Certo, ci si spreca un po di tempo in più, ma alla lunga paga.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> Anch'io ho una certa qual esperienza del tipo di> progetti citati nell'articolo.> IMHO:> [...]> > 3. quando i tempi totali di sviluppo superano i> sei mesi/un anno si corre il serio rischio che le> necessita' nel frattempo cambino, che i> responsabili cambino, ecc. ecc. per cui se si> vuole evitare la catastrofe e' fondamentale che> il primo collaudo avvenga entro questo arco> temporale> > 4. gli sviluppi vengono fatti fare ai soliti> giovanissimi nelaureati da 800 euro/mese> attraverso una catena interminabile di> subappalti: la qualita' del codice e' infima, le> scelte architetturali ingenue (per una form di> memorizzazione sul database da erogarsi a milioni> di pagine al giorno si usano piattaforme java con> catene di ereditarieta' infinite, quando un aspx> o un php sarebbe due ordini di grandezza piu'> performante e piu' corto da scrivere; Italia.it> lo scrivono con Joomla e poi si meravigliano che> non regge la botta degli accessi..ecc.> ecc.)Mi ricorda tanto questo diagramma:http://xkcd.com/844/

Re: alcuni motivi del disastro...
Intervengo solo per darti ragione. Sei uno dei pochi che ha capito perfettamente come si lavora(in ambito IT) in Italia e quali sono le reali problematiche di grossi progetti. Insomma, intuisco che hai esperienza.Io credo che la vera ragione del perchè i progetti IT falliscono è che chi te lo commissiona non ha le idee chiare.

Re: alcuni motivi del disastro...
- Scritto da: ciliani> Anch'io ho una certa qual esperienza del tipo di> progetti citati nell'articolo.> IMHO:> > 1. si sopravvaluta troppo la fase progettuale:> sono tutti progettisti raffinati e nessuno sa> scrivere codice. Si spende tempo e denaro in> complicati documenti pieni di UML e compagnia> bella, ma il committente non e' in grado di> capirli e approva cose di cui non si rende conto> appienoSemplicemente (e anch'io ho una certa esperienza in merito con enti centrali) il 99% della gente che lavora in tali enti centrali non capisce un bel niente di progettazione informatica. Aggiungici il fatto che vogliono il progetto completato in tempi minimi (perche i quadri e dirigenti ci prendono il premio - ebbene si! In alcune relatà della PA vengono valutati non per aver portato il progetto a compimento in modo corretto ma l'averlo portato nei tempi dovuti che sono sempre estremamente ristretti. Aggiungici il fatto che lo stato vuol pagare una figura di esperto (qualsiasi sia) 300 euro al giorno quando va bene, cosa si pretende allora?> > 2. nessuno, neanche gli Einstein della> progettazione, sono in grado di prevedere con> precisione le funzionalita' che il sistema dovra'> avere davvero. Ci si puo' avvicinare, ma solo> quando il committente comincia ad usare il> prodotto si rendera' conto di cosa manca e di> cosa invece c'e' ma non serve a nulla. Chi crede> che si possa prevedere e i bravi ci riescono e'> un illuso. L'unico modo di sviluppare sistemi> funzionanti e' la "beta permanente": si fa una> demo funzionante delle cose fondamentali nel giro> di poche settimane, si fa vedere agli utenti e> via via si aggiusta aggiungendo e correggendo le> funzionalita' fino ad avere tutte e solo le> funzioni necessarie. Un po' alla volta si> costruisce il sistema in modo> incrementale.>D'accordo con te ma come descritto sopra sono "i tempi di rilascio" quelli che non vanno. Soprattuto nel campo in cui lavoro io (DataWarehouse)> 3. quando i tempi totali di sviluppo superano i> sei mesi/un anno si corre il serio rischio che le> necessita' nel frattempo cambino, che i> responsabili cambino, ecc. ecc. per cui se si> vuole evitare la catastrofe e' fondamentale che> il primo collaudo avvenga entro questo arco> temporale> Benissimo...sulla carta...> 4. gli sviluppi vengono fatti fare ai soliti> giovanissimi nelaureati da 800 euro/mese> attraverso una catena interminabile di> subappalti: la qualita' del codice e' infima, le> scelte architetturali ingenue (per una form di> memorizzazione sul database da erogarsi a milioni> di pagine al giorno si usano piattaforme java con> catene di ereditarieta' infinite, quando un aspx> o un php sarebbe due ordini di grandezza piu'> performante e piu' corto da scrivere; Italia.it> lo scrivono con Joomla e poi si meravigliano che> non regge la botta degli accessi..ecc.> ecc.)>Con le tariffe che applicano ti meraviglieresti del contrario? > 5. la catena infinita che dal primo vincitore> della gara porta all'ultimo livello dei peones> che veramente sviluppano obbliga a costi> spaventosi, tutti devono fare un bel markup e poi> con i soldi che restano ci si deve accontentare> del programmatorino che l'unico programma che ha> scritto prima e' la rubrica telefonica personale> (e che neanche> funziona)> Leggi alla voce: Tariffe> Per concludere: ho avuto qualche volta la netta> sensazione che qualche societa' di consulenza di> quelle davvero grosse sfrutti a proprio vantaggio> questa situazione appositamente progetti sistemi> software enormi che non potranno andare in> esercizio. A quel punto non sviluppano proprio il> sistema, oppure fanno finta mettendo insieme un> po' di codice non funzionante e non testato,> tanto non entrera' mai in esercizio e loro> risparmiano tutti i costi di> sviluppo.Può anche essere (qualche volta mi è capitato di vedere situazioni del genere) ma ricordiamo i due fattori che purtroppo i cari enti pubblici impongono a chi vince una gara (che ricordiamo sono al ribasso):1. Tempi al di fuori del ragionevole 2. Prezzi applicati alle figure previste in contratto.

Re: alcuni motivi del disastro...
In 2 parole:http://dilbert.com/strips/comic/2011-02-03/

Osservatorio prezzi carburante
A parte i mille ritardi e qualche piccolo intoppo sembrerebbe che con il monitoraggio dei prezzi del carburante siano riusciti a fare qualcosa di decente:http://carburanti.osservaprezzi.it/

Re: Osservatorio prezzi carburante
- Scritto da: Stefano> A parte i mille ritardi e qualche piccolo intoppo> sembrerebbe che con il monitoraggio dei prezzi> del carburante siano riusciti a fare qualcosa di> decente:> > http://carburanti.osservaprezzi.it/Sei ironico?Spero di sì, perché un servizio che si propone come statistico e come campioni in Lombardia dà 8 impianti mi sembra scarso.

Re: Osservatorio prezzi carburante
Solo un pochino :-)Tanto per dirne una, esiste una piattaforma (non posso fare pubblicità ma con google la trovi subito) che permette il monitoraggio dei prezzi di tutti i distributori di carburante (e non solo quelli autostradali) già dal 2004.Purtroppo i prezzi inseriti sono pochini.

Re: Osservatorio prezzi carburante
- Scritto da: Stefano> A parte i mille ritardi e qualche piccolo intoppo> sembrerebbe che con il monitoraggio dei prezzi> del carburante siano riusciti a fare qualcosa di> decente:> > http://carburanti.osservaprezzi.it/ma se neanche la ricerca per campi riporta dati corretti...chi l'ha fatto topo gigio ?

c'è un altro aspetto
c'è un altro aspetto da prendere in considerazione: ma siamo sicuri che il proponente sia interessato affinchè il progetto giunga a completamento o già dall'inizio era previsto l'impantanamento del prodotto?Quando un progetto finisce tutti i nodi vengono al pettine, se non finisce invece...

...e il SISTRI?
Il sistema informatico di tracciabilita di rifiuti? questo dove lo mettiamo? provate a informarvi sui costi di gestione e utilizzazione dopo 2 anni di proroghe.. italia.it vi sembrera una bazzecola!Selex->finmeccanica .. i soliti furbetti!

Re: ...e il SISTRI?
- Scritto da: Persona informata sui fatti> Il sistema informatico di tracciabilita di> rifiuti? questo dove lo mettiamo? Il sistri è un delirio. Sto aiutando alcune aziende private ad implementarlo e ho i conati di vomito....password che non funzionano, asisstenza meno preparata di chi telefona per una assistenza, ecc, ecc

Re: ...e il SISTRI?
Sembra che sia esattamente così, soprattutto ingestibile nel carico e scarico merci e pieno di buchi come la groviera per il tracciamento!

il vero problema
il problema sono i committenti, lo stato sfacelo che abbiamo, con ammanicati e parenti e amici dei partiti/politici di turno, che pensa che nell'emettere una norma o un regolamento o un appalto si compia tutto il suo dovere, poi automagicamente le cose si fanno da sole, tanto non deve rendere conto dei risultati ma solo della sua obbedienza a un capò.

sono un testimone della questione
Concordo, le posso dare io le notizie di prima mano, anche per progetti piccoli (2/3 Mln di euro) a cui la mia azienda ha partecipato, ed è andata esattamente come raccontate: una marea di consulenze per eGov e il 15% finito in vero sistema informativo

D'accordo!
Niente da aggiungere all'ottima analisi, se non che in questa situazione la crisi ed il taglio dei finanziamenti ai mega progetti è paradossalmente una fortuna.

in italia assumono solo in base...
Al compenso (per questo assumono giovanissimi spesso alle prime armi) o al titolo di studio (magari laureati al cepu :D) sono poche le aziende che provano sul campo la conoscenza tecnica, spesso a fare colloqui non sono nemmeno dei tecnici, in reala è pure colpa delle amministrazioni io non firmerei mai un accordo multimilionario con una società che non mi da garanzie (anche economiche) in caso di fallimento o problemi simili, e ovviamente renderei illegale il subappalto, perchè ho visto lavori subappaltati 6 volte. Praticamente la società o PA commissiona un lavoro da 100.000 euro a B (spesso B è una società fatta apposta per rubare soldi pubblici). B che essendo pensata solo per rubare soldi non ha risorse informatiche per realizzare il lavoro e cerca una società a cui dare il lavoro in cambio di 60.000 se ti dice bene quella società fa il lavoro senno si continua fino ad arrivare a una società che fa il lavoro per 5000 euro un programmatore lo paghi si e no per 2 mesi quindi quel programmatore magari deve fare un lavoro biblico in 2 mesi. Basterebbe vietare il subappalto che in informatica è inutile e genera soltanto costi e qualità scarsa.

Re: in italia assumono solo in base...
Il subappalto adrebbe vietato in tutti i settori, per me. Piuttosto Piuttosto riducano l'ampiezza del lotto in appalot, così da permettere a più aziende di parteciparvi.

Re: in italia assumono solo in base...
Urg, mi scuso degli errori di battitura :P

Re: in italia assumono solo in base...
No no...Non è sempre così. Mettici pure i casi del:Metto sul piatto 100000 euro per avere la superXXXXXla (ma avere la superXXXXXla dovrei sborsare 1 milione) ma non ci capisco un bel niente.Ce ne sono diversi così ;)

informazioni di prima mano...
Caro Marco, Non ho informazioni di prima mano. io invece, ahimé, ne ho eccome... e per diretta, vasta e pluriennale esperienza dall'INTERNO della PA... Ma la sensazione netta è che come al solito in Italia i mega-progetti ricchi di finanziamenti siano anche ricchissimi di figure manageriali, politiche, amministrative, e che gli esperti informatici e di organizzazione siano relegati in fondo alla piramide decisionale e realizzativa, a spendere gli spiccioli rimasti con risorse insufficienti, carenza di informazioni ed assenza di un reale coordinamento. posso assolutamente confermarti che questa tua senzazione è perfettamente aderente alla realtà...ma è "solo" parziale... perché però, se possibile, le cose stanno pure peggio: - quasi sempre i mega-progetti (=mega-appalti) vengono praticamente e letteralmente INVENTATI per gli "scopi" che hai giustamente immaginato (e ci credo che poi si tratta di cose inutili e/o con obiettivi non chiari...)- in qualche caso si fanno i progetti SAPENDO benissimo che sono sbagliati (sì, c'è proprio una precisa volontà nel fare così): se un progetto è ben fatto e tutto va bene, allora la cosa rischia di finire lì... ma se si fa un progetto sbagliati, allora poi si deve fare subito un altro bel progetto (=un altro finanziamento) per "correggere" il primo...- e il tutto viaggia secondo le ben note modalità (previste dalle leggi... mai fatte a caso...) con cui si effettuano gare d'appalto, esecuzione, collaudi ecc. - a tutti i livelli "tecnici" e "operativi": . idee, volontà e decisioni di politici e amministratori (dai più alti fino ai più oscuri consiglieri comunali). progetti (di progettisti tanto "capaci" e "brillanti" quanto meno esperianza dimostrano in materia). qualità e capacità tecnica degli affidatari (spesso riunioni estemporanee dei soliti più o meno grandi "soggetti" noti, ne hai citati alcuni nell'articolo, affiancati da qualche società creata apposta per l'occasione, tra i cui soci si trovano facilmente parenti e amici dei soliti personaggi noti...). soggetti esecutori (subappaltatori vari ed eventuali, piccoli e grandi...). manager e professionisti vari che dirigono, coordinano e conducono i "lavori".... "esperti" . ecc. ecc.bene, a tutti questi livelli, regnano sovrani incontrastati: stupidità, pressapochismo, presunzione, ignoranza (basta vedere i progetti, le offerte, i report, i verbali...: non sembrano neanche scritti in italiano... ci sono più errori che parole), incompetenza, inesperienza e via dicendo...e non ho più voglia di continuare... già basta e avanza...un caro saluto

Non dimenticare ..
Non dimenticare quel bando di gara del ministero dell'innovazione (!!!), con obbligo di presentazione tramite PEC (la famosa posta elettronica certificata tanto obbligatoria quanto utile), che finiscono in un fallimento a causa di "mailbox full", un problema che solo in Italia è impossibile da prevedere.Oppure quel magnifico progetto SISTRI (in pratica un software applicativo per la registrazione dei trasporti dei rifiuti), nato con obbiettivi condividibili, con tecnologie all'avanguardia, ma con competenze applicative nulle (come se me e te ci mettessimo a scrivere da zero un software per registrare le spedizioni spaziali) e project managemnt ridicolo. A 2 anni dall'inizio finora solo rinvii dell'entrata in funzione.

Re: Non dimenticare ..
- Scritto da: Alessandro Landi> Non dimenticare quel bando di gara del ministero> dell'innovazione (!!!), con obbligo di> presentazione tramite PEC (la famosa posta> elettronica certificata tanto obbligatoria quanto> utile), che finiscono in un fallimento a causa di> "mailbox full", un problema che solo in Italia è> impossibile da> prevedere.> Oppure quel magnifico progetto SISTRI (in pratica> un software applicativo per la registrazione dei> trasporti dei rifiuti), nato con obbiettivi> condividibili, con tecnologie all'avanguardia, ma> con competenze applicative nulle (come se me e te> ci mettessimo a scrivere da zero un software per> registrare le spedizioni spaziali) e project> managemnt ridicolo. A 2 anni dall'inizio finora> solo rinvii dell'entrata in> funzione.ottimo ottimo!ne si parla troppo pocoPochi hanno parlato anche dell'intrastat ... e dei casi in cui la legge prevedeva una scadenza e adeguamento a determinate direttive... che coinvolgono una trasformazione del protocollo e un aggiornamento del software... e il giorno stesso della scadenza il software non era pubblicato... ne sapevano di più i vari ragionieri e contabili (che giustamente da bravi fiscali e puntigliosi tritavano i tenerini ai vari ced ... i quali si trovavano senza controparti ufficiali ...)C'è anche da dire che oggi che l'informatica viene trattata come argomento da supermercato c'è mancanza di veri tecnici anche dentro le aziende... ma questo non toglie che da parte della PA la semplificazione sia spesso tale solo di nome, lo snellimento altrettanto.A questo punto i rinvii non possono che essere benvenuti. Almeno tutte quelle cose mezze dubbie ... restano in sospeso.

Esempi sbagliati
I megaprogetti informatici pubblici falliscono più o meno come falliscono quelli degli ospedali ipertecnologici mai aperti le strade che non vanno da nessuna parte e tutte le altre cattedrali nel deserto. Questi progetti pensati soprattutto per far girare i soldi e falliscono solo per mancanza di interesse. Una volta incassati i soldi nessuno alza un dito per completare il lavoro.Progetti di questo tipo non si possono paragonare con gli altri fallimentari progetti portati avanti sia nel settore pubblico che quello privato.

Re: Esempi sbagliati
- Scritto da: guast[...]> Progetti di questo tipo non si possono paragonare> con gli altri fallimentari progetti portati> avanti sia nel settore pubblico che quello> privato.tipo?

Re: Esempi sbagliati
- Scritto da: cittadino39 487> - Scritto da: guast> [...]> > Progetti di questo tipo non si possono> paragonare> > con gli altri fallimentari progetti > portati> > avanti sia nel settore pubblico che quello> > privato.> > tipo?Tipo quelli per cui la grande azienda a caso spende un sacco di soldi, ma al solito giro di ricambio dei manager un'altra fazione prende il sopravvento e decide di ammazzare il progetto.Tipo quelli progettati tanto male che sono pieni di bugs.Gli sviluppatori ci lavorano su giorno e notte, ma ogni volta che si martella da una parte si scassa dall'altra, alla fine il cliente si stufa e abbandona il progetto.Tipo quelli in cui il markettero e il cliente non si capiscono e alla fine viene fuori qualcosa che non serve a niente e nessuno usa.

Progettazione&Realizzazione in generale
Io abito in un'appartamento in un condominio ex-167 (popolare) realizzato a fine anni '70 in un paese di piccole dimensioni. Dopo 30 anni di uso, io ci abito da 5, il condominio ha avuto bisogno solo di manutenzione ordinaria. Per capirsi la caldaia condominiale per il riscaldamento ha avuto solo la sostituzione del bruciatore per passare da gasolio a metano. Questa è stata la manutenzione straordinaria più grande in 30 anni.I miei genitori dopo 50 anni di fatica hanno comprato la casa dei loro sogni 7 anni fa, villetta del valore di 300k in collina, nuova di zecca.Quella casa è un delirio, progettata male, realizzata con una scarsissima qualità di materiali. Dopo 2 anni in marciapiede che circonda la casa è letteralmente crollato perchè la terra di riporto sotto non era stata battuta e nessuno aveva pensato di mettere ferri dentro questo marciapiede per evitare questi inconvenienti.Parto da questi due esempi perchè i modelli con i quali sono stati costruite queste due abitazioni sono secondo me significativi:1- Modello anni '70: Scopi chiari, progettazione adeguata (anche nei costi), realizzazione delegata ad una ditta grande con pochissima delega a cottimisti.Risultato: non una casa da re ma appartamenti da 80 metri realizzati a dovere con la resistenza al tempo che ci si aspetta da una casa. La cosa più interessante è la lungimiranza: tutti i condomini gemelli al mio (5 blocchi da 8 appartamenti) non hanno l'ascensore per abbattere i costi, ma hanno la predisposizione (la tromba dell'ascensore).2- Modello nuovo millennio: scopo fare profitto molto chiaro, progettazione strapagata, materiali di scarsa qualità realizzazione di una singola villetta che ha compreso almeno 10-12 ditte diverse con molta fretta di finire il proprio lavoro e scarsissima attenzione alla qualità.Risultato non pessimo ma quasi, scale strette ed esterni già da rifare. Come risultato finale non hanno nemmeno asfaltato il vialetto che porta al garage (a carico dei miei genitori come extra) come il depuratore dell'acqua.Il secondo modello è quello applicato oggi per qualsiasi cosa venga progettata e realizzata, compreso i servizi web.Progettazione strapagata, strumenti di realizzazione inadeguati e cottimisti con molta fretta di finire il lavoro senza curarsi della qualità del prodotto. Pochi mesi uomo per lavori che ne richiederebbero almeno una volta e mezzo o due per le fasi di debug e di stress del sistema che non vengono mai ultimate. Tutto questo quando non ci sono grossi problemi sulla progettazione, comunque strapagata.Parlo da progettista ex-developer.

Re: Progettazione&Realizzazione in generale
Già, così stanno le cose.

Marco, continua così
Ottimo Marco.Ti prego di continuare così, con inchieste "alla report" o "iene" sull'inefficienza informatica della macchina statale.Spesso il semplice cittadino si chiede "ma perché non fanno così?" e il "così" è in effetti la soluzione logica e semplice. A volte, lo ammetto, mentre quasi sempre non è così. Ma accade spesso. Mentre invece altre volte è evidente che qualsiasi scelta non è nata da chi mastica la tecnologia da tempo e conosce potenzialità, pregi e difetti.Quindi continua, fai indagini, fai test e reportage "alla Attivissimo" che sicuramente farai cosa buona e giusta.Ad esempio chiediamoci anche: perché tutte le procedure amministrative/contabili (vedi sito entrate) costringono all'uso di una certa versione di java quando alla maggioranza dell'utenza (anche aziendale, se il sysadmin ritiene necessario aggiornare) viene richiesto di aggiornare per motivi di sicurezza la VM?Perché in altre, mi dicono ad esempio ministero della sanità, sembra sia suportato solo un certo browser e la procedura per il riconoscimento della smart card o della firma digitale sia piuttosto complicato?In ogni caso anche se siamo amanti della tecnologia (e quindi ci aspettiamo in quell'ambito almeno una parziale tecnocrazia) bisogna ricordare: ma perché il cittadino non informatizzato non ha alternative?Ok, sto uscendo dal seminato perché parli di ciclo interno alla PA ... però... per i prossimi numeri... di ciccia ce n'è, Marco: continua a metterla sul girarrosto! :)

Re: Marco, continua così
sulle smart card e la firma è un delirio... io con la mia banca ho il generatore di codici che se volessi potrei usare per la firma (pagando il servizio) ... se lo fanno le banche non credo sia insicuro... ed è indipendente da qualsiasi OS,Browser o hardware... bho...

ingegneri
La progettazione non dovrebbe essere di politici, operatori dell'informatica autodidatti e così via... ma di ingegneri progettisti..... del terzo settore!

Re: ingegneri
- Scritto da: Fabio De Agostini> La progettazione non dovrebbe essere di politici,> operatori dell'informatica autodidatti e così> via... ma di ingegneri progettisti..... del terzo> settore!riusciamo a fare enormi XXXXXte anche senza il loro qualificato aiuto.

In Italia
Il video riassume come funzionano le cose da noi:http://www.youtube.com/watch?v=jLvpXVWXDK4

Re: In Italia
ROTFL .. purtropppo è verissimo

it != ITALIA --> IT === "Bunga bunga"
EMPTY!!!EMPTY!!!non aggiungo altro

Stato = mucca da mungere
E questa affermazione siamo noi che la rendiamo valida, intendo noi cittadini italiani abituati a questo andazzo. Abbiamo un'arma, il voto, ma chi la usa?

Re: Stato = mucca da mungere
il voto serve solo se hai qualcuno da scegliere ...

Re: Stato = mucca da mungere
- Scritto da: abacab> il voto serve solo se hai qualcuno da scegliere> ...non sono tutti uguali, solo che devi dare una priorità a quello che vuoi secondo me. ad esempio, ci sono quelli che faranno leggi a favore della legalità, quelli a favore delle fasce più deboli, quelli a favore dell'imprenditoria, quelli a favore del federalismo, quelli a favore dell'ecologia, eccdevi solo decidere da cosa vuoi iniziare, non importa se non sono capaci di fare tutto

Re: Stato = mucca da mungere
http://www.youtube.com/watch?v=OqPArh99deE

Re: Stato = mucca da mungere
Io ho solo visto gente che ruba soldi e NON fa leggi o quando le fa fa solo XXXXXXX... da tutti o poli/fazioni/schieramenti...

Re: Stato = mucca da mungere
- Scritto da: Lemon> - Scritto da: abacab> > il voto serve solo se hai qualcuno da scegliere> > ...> > non sono tutti uguali,E' vero.Ci sono i criminali, gli inutili e gli incapaci.Ma una cosa li accomuna, non vivono nel nostro stesso mondo e non hanno i nostri stessi problemi.Pretendere soluzioni da gente come questa, anche se fosse onesta e animata dalle migliori intenzioni è pura follia.> ad esempio, ci sono quelli che faranno leggi a> favore della legalità, quelli a favore delle> fasce più deboli, quelli a favore> dell'imprenditoria, quelli a favore del> federalismo, quelli a favore dell'ecologia,> eccSei un romantico sognatore.

"obbiettivi inconfessabili"
Sono questi che fanno fallire i progetti. E il Paese.

Complimenti a PI
L'unico ramo di discussione interessante è stato amputato per motivi sconosciuti. Fate pena.

... e le responsabilità penali ...?
dove le mettiamo?La procedura obbligatoria ad uso dei medici di famiglia per l'invio telematico dei certificati di malattia implica il trattamento di dati medici, coperti dal D.Lgs. 196/2003 (legge sulla privacy).La legge ha messo nelle mani di questo sistema (in realtà di chi è titolare del trattamento gestito attraverso di esso) la responsabilità penale inerente i dati trattati.E la legge non parla soltanto di diffusione non autorizzata: la legge copre gli aspetti di riservatezza, integrità e DISPONIBILITÀ.I dati devono essere disponibili ai portatori di interesse quando ne hanno bisogno.I medici rischiano denunce penali per colpa degli incompetenti che hanno progettato, realizzato e collaudato il sistema.E ci sarebbe anche da aggiungerem credo, la responsabilità penale per l'interruzione del pubblico servizio: ribadisco, se un cittadino rischia il penale per la disfunzione del sistema, qualcuno deve assumersi le relative responsabilità.Ma finirà come sempre a tarallucci e vino, e poi nel dimenticatoio ...In ogni caso il Garante per la Privacy dovrebbe muoversi: il sistema tratta dati sensibili, e deve essere dotato di un DPS che comprovi tutte le misure adeguate adottate per assicurare la disponibilità delle informazioni agli interessati.

Servizi che non servono
Se ad un servizio internet internet creato , corrispondesse ad un servizio fisico spento il giorno dell'avvio (esempio:tutti i servizi al banco del comune sul web = chiudo sportello fisico in comune)TUTTI si lamenterebbero del progetto fallito,PERCHE' ne avrebbero bisogno SUBITO , invece così il sito non funziona , i manager hanno preso le loro belle mazzette ,e quelli dello sportello se la ridono,noi vediamo un sito che non va e non possiamo fare niente,se non pagare ogni anno il 40% di tasse.Insomma :evviva il paese delle banane.

Grazie per la censura... rammentero
Avevo risposto a questo messaggio...http://punto-informatico.it/b.aspx?i=3082733&m=3083425#p3083425Tra le altre cose con toni molto neutrali nel giudizio della classe politica.Nel senso che non desinavo critiche ne all'attuale "governo" ne tanto meno all'"opposizione"accusando quello che a mio modo di vedere è il vero problema italiano ossia la mancanza del Senso dello Stato dei Cittadini.Il bello è che è stato cancellato giorni dopo... in modo che tutto non fosse notato.Potete adesso raccontarmi (o raccontarvi?) della censura randomica che c'è qui http://nonciclopedia.wikia.com/wiki/Punto_Informatico#Sistema_di_moderazionela verità è che invece è molto mirata e selettiva... persino retroattiva a quanto pare.Davvero bravi.Ma ditemi il vero, confidatevi, alcuni degli anonimi sono anche redattori e quando qualcuno li mette con le spalle al muro (dialetticamente parlando) se lo lega al dito e gli rimuovete il messaggio?Ecco spiegato perché sembrano solo messaggi di Troll ... quelli un pò più articolati li rimuovete.Non è la prima volta che mi capita, ma censurare una stupida questione sui sistemi operativi, mi interessa il giusto... Su argomenti un "tantinello" più seri... mi fa rabbrividire.Brrrr.Congratulazioni!

Il difetto della semplicità
Nell'organizzazione della cosa pubblica ci sono montagne di adempimenti informatizzabili che ben si presterebbero a semplificare gestione e controllo.Molte volte sono cose semplici che lievitano in progetti faraonici.Ben vengano le cose semplici ed efficaci meno gli orpelli.Quindi si parte con un progetto per farle, ma il progetto lievita, diventa un megaprogetto per cui l'utile si porta dietro l'inutile, la relativa complessità i relativi costi e pericoli di insucXXXXX.Storiella esemplificativa:Dobbiamo comprare un armadietto, andiamo allo store, scegliamo quello che ci piace compatibile con il nostro portafoglio, lo portiamo a casa, ci mettiamo su i libri.Una pubblica amministrazione si fa fare i preventivi, dato che paga tardi non ci si stupusce se glieli raddoppiano.Poi non possiamo comprare il 'modello base', se poi non va ci danno degli incompetenti, per non sbagliare prendiamo l'ultimo modello al titanio.Per non avere poi il collega che ti critica perché non ne hai comprato uno in linea con le nuove disposizioni (puro esempio) che entreranno in vigore il prossimo decennio, lo prendi con queste caratteristiche.Devi trovare il trasportatore che lo va a prendere e ti devi far fare il preventivo.Non lo puoi mettere tu ma devi trovare il posatore di armadietti (per evitare critiche), ti fai fare il preventivo.Poi ci sarà sempre il dipendente che lamenterà che un armadietto così difficile da usare richiede un apposito corso, ti fai fare il preventivo.Alla fine esce una cifra stratosferica, ma hai dato da lavorare al venditore di armadietti, al trasportatore, al posatore, al formatore, al dipendente che riceverà la formazione.Risultati:Caso 1:paghi un XXXXXio di soldi dove con un armadietto più semplice trasportato con la tua macchina, avresti avuto gli stessi risultati in un ora spendendo dieci volte meno.Caso 2:non ci sono soldi per comprare l'armadietto come 'ci serve', appoggiamo i libri per terra.Caso 3:il trasportatore non ha tempo, si ammala il formatore, fallisce la ditta, insomma avrai l'armadietto quando te ne serviranno quattro o semplicemente non arriverà mai.Caso 4:finalmente hai l'armadietto ma nessuno lo usa perché agli utenti piaceva giallo ed un armadietto di quel colore non lo useranno mai.

E nel privato ?
Sarà ma anche nel privato vedo molte delle cose citate nell'articolo e nei commenti ...