Pwn2Own, Chrome si mette alla prova

Google alza la posta in palio della nota competizione di hacking: 20mila dollari di premio per chi riuscirà a violare la sandbox

Roma – Manca ormai un mese all’edizione 2011 del Pwn2Own , la celebre sfida di hacking ospitata dalla convention sulla sicurezza CanSecWest che mette sotto torchio i principali browser web. Lo scorso anno Safari, Internet Explorer e Firefox hanno tutti ceduto agli exploit degli esperti iscritti al contest. L’unico browser ad opporre resistenza ai colpi degli hacker è stato Chrome .

Per l’edizione di quest’anno la commissione del Pwn2Own aveva deciso di non scomodare il software di navigazione marchiato Google. La motivazione ufficiale dell’esclusione verteva sul fatto che la “cavia” Chrome, fondamentalmente, si basa sullo stesso motore Webkit utilizzato dal browser Apple. Ma il colosso di Mountain View non ci sta: in un modo o nell’altro Chrome deve partecipare.

Dopo aver chiesto agli organizzatori dell’evento di riconsiderare la lista dei software inclusi, Google ha anche messo in palio una cifra extra (20.000 dollari) per ogni esperto di sicurezza che riuscirà a trovare una vulnerabilità nella blindatissima sandbox di Chrome.

BigG ha tirato poi in ballo il suo fiammante netbook Cr-48 , equipaggiato con sistema operativo Chrome OS. Gli “exploit writer” che riusciranno a vincere le protezioni innalzate dagli ingegneri Google otterranno in premio anche questo laptop.

Roberto Pulito

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Tizio Qualunque scrive:
    E nel privato ?
    Sarà ma anche nel privato vedo molte delle cose citate nell'articolo e nei commenti ...
  • paoloholzl scrive:
    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.
  • si fa per parlare scrive:
    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!
  • giuseppe impavido scrive:
    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.
  • andy61 scrive:
    ... 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.
  • dont feed the troll/dovella scrive:
    Complimenti a PI
    L'unico ramo di discussione interessante è stato amputato per motivi sconosciuti. Fate pena.
  • ruppolo scrive:
    "obbiettivi inconfessabili"
    Sono questi che fanno fallire i progetti. E il Paese.
  • Lemon scrive:
    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?
    • abacab scrive:
      Re: Stato = mucca da mungere
      il voto serve solo se hai qualcuno da scegliere ...
      • Lemon scrive:
        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
        • upr scrive:
          Re: Stato = mucca da mungere
          http://www.youtube.com/watch?v=OqPArh99deE
        • abacab scrive:
          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...
        • dont feed the troll/dovella scrive:
          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.
  • upr scrive:
    it != ITALIA --
    IT === "Bunga bunga"
    EMPTY!!!EMPTY!!!non aggiungo altro
  • abacab scrive:
    In Italia
    Il video riassume come funzionano le cose da noi:http://www.youtube.com/watch?v=jLvpXVWXDK4
  • Fabio De Agostini scrive:
    ingegneri
    La progettazione non dovrebbe essere di politici, operatori dell'informatica autodidatti e così via... ma di ingegneri progettisti..... del terzo settore!
    • shevathas scrive:
      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.
  • cittadino39 487 scrive:
    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! :)
    • abacab scrive:
      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...
  • Maledetto Vespa scrive:
    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.
  • guast scrive:
    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.
    • cittadino39 487 scrive:
      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?
      • guast scrive:
        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.
  • Alessandro Landi scrive:
    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.
    • cittadino 39487 scrive:
      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.
  • che pena scrive:
    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
  • Regur Mortis scrive:
    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.
    • Maestro Miyagi scrive:
      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.
    • infa scrive:
      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ì ;)
  • Paolo scrive:
    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.
  • Alessandro Villani scrive:
    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
  • ricciolo scrive:
    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ò.
  • Persona informata sui fatti scrive:
    ...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!
    • AMEN scrive:
      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
    • Maledetto Vespa scrive:
      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!
  • pietro scrive:
    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...
  • Stefano scrive:
    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/
    • Teo_ scrive:
      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.
      • Stefano scrive:
        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.
    • Picchiatell o scrive:
      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 ?
  • ciliani scrive:
    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.
    • Teo_ scrive:
      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!?
      • ciliani scrive:
        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 ;-)
        • Teo_ scrive:
          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.
          • ciliani scrive:
            Re: alcuni motivi del disastro...

            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.Anch'io non ci vedrei nulla di male, il punto pero' e' che forse non e' la tecnologia in grado di reggere milioni e milioni di accessi al giorno. Puoi anche aggiungere batterie di front-end (tanto paghiamo noi) pero' costa meno ed e' piu' efficiente fare una paginetta di visualizzazione di dati su database senza passare per trecento livelli di codice che chiama altro codice. Sistemi come Joomla sono fatti per assicurare una grande flessibilita', e per questo ogni singola paginetta diventa il risultato di migliaia di righe di codice che vengono elaborate (e piu' o meno interpretate... o da un interprete php o da una macchina virtuale java...) per ogni richiesta. E' il prezzo da pagare per chi vuole mettere su un sito di contenuti potente e flessibile senza dover pagare per svilupparlo; ma sono pochi i siti fatti in questo modo che superano le poche migliaia di pagine erogate al giorno.Avrebbe molto piu' senso se come dici tu qualcuno si fosse preso la briga di ripulire il codice dalle parti non utili, ma questa e' una cosa che non fa quasi nessuno, temo. Ne' sarebbe facile: costerebbe di piu' che scrivere quelle cinque o dieci pagine .aspx o .php necessarie per erogare il servizio.
          • vik scrive:
            Re: alcuni motivi del disastro...
            Se pensi che il collo di bottiglia sia il tempo di esecuzione del codice proprio non ci siamo. In una webapplication i porblemi sono molti altrima di arrivare al tempo di esecuzione del codice.Ameno che non sia scritto proprio male, ma seve mettercisi di impegno e farlo apposta, il porblema di solito non è a livello di tempo di esecuzion del codice. Solitamnente è a livello di architettura del sistema
    • HappyCactus scrive:
      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.
      • ciliani scrive:
        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.
        • HappyCactus scrive:
          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.
          • ciliani scrive:
            Re: alcuni motivi del disastro...
            Giusto per dirti che la progettazione io la faccio e la superivisiono nei progetti piu' grossi; e l'universita' l'ho fatta molti anni prima di te. Ma poi ho anche lavorato sul mercato ed ho accumulato esperienza. La progettazione va fatta, ovviamente, ma credi a me e' impossibile prevedere all'atto della progettazione tutto quanto sarebbe necessario. Questo lo dice la mia esperienza ventennale e lo dicono anche i professori universitari seri. Sono sicuro che quando anche tu avrai sviluppato un certo numero di sistemi informativi complessi capirai quello che stavo dicendo. E' ovvio che una buona progettazione la devi fare prima, ma e' necessario che la progettazione sia poi modificata ed aggiustata in corso d'opera via via che si collaudano le funzionalita'.Inoltre ti potrei enumerare le mode informatiche che c'erano quando ho fatto l'universita' io (la programmazione strutturata, la structured systems analysis di Tom DeMarco, ecc.). Sono scomparse sostituite da altre mode, adesso c'e' UML, Agile Development, ecc.... fra dieci anni ce ne saranno altre. Il fatto e' che l'ingegneria software non ha ancora raggiunto la maturita' di altre ingegnerie (come ad esempio quella meccanica, puoi progettare un sottomarino prevedendo l'esatto numero di vitarelle necessarie, come sappiamo tutti noi "che abbiamo studiato").Comunque mi piacerebbe sapere quali grandi sistemi informatici hanno realizzato i professori universitari che ti hanno inculcato tutta questa sicurezza.
          • shevathas scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: ciliani
            Giusto per dirti che la progettazione io la
            faccio e la superivisiono nei progetti piu'
            grossi; e l'universita' l'ho fatta molti anni
            prima di te. Ma poi ho anche lavorato sul mercato
            ed ho accumulato esperienza. La progettazione va
            fatta, ovviamente, ma credi a me e' impossibile
            prevedere all'atto della progettazione tutto
            quanto sarebbe necessario. ovviamente no, ma sarebbe gradito avere idee almeno a grandi linee di cosa dovrebbe fare il software, poi ovviamente il macro obiettivo lo esplodi in una serie di sotto obiettivi. Ma se non si hanno le idee chiare almeno sul macro obiettivo sicuramente ci si sta fiondando verso un fiasco colossale.
            Questo lo dice la mia
            esperienza ventennale e lo dicono anche i
            professori universitari seri. Sono sicuro che
            quando anche tu avrai sviluppato un certo numero
            di sistemi informativi complessi capirai quello
            che stavo dicendo. E' ovvio che una buona
            progettazione la devi fare prima, ma e'
            necessario che la progettazione sia poi
            modificata ed aggiustata in corso d'opera via via
            che si collaudano le
            funzionalita'.
            è stupido credere che fatta la progettazione questa possa essere incisa in lastre di granito e lasciata fissa per l'eternità ma parimenti è XXXXXXXXX andare avanti per tentativi stravolgendo tutto ad ogni piè sospinto. Il problema è che se il committente non capisce neppure lui cosa vuole e cosa deve farci è praticamente impossibile accontentarlo.
            Comunque mi piacerebbe sapere quali grandi
            sistemi informatici hanno realizzato i professori
            universitari che ti hanno inculcato tutta questa
            sicurezza.
          • ciliani scrive:
            Re: alcuni motivi del disastro...

            è stupido credere che fatta la progettazione
            questa possa essere incisa in lastre di granito e
            lasciata fissa per l'eternità ma parimenti è
            XXXXXXXXX andare avanti per tentativi
            stravolgendo tutto ad ogni piè sospinto. Il
            problema è che se il committente non capisce
            neppure lui cosa vuole e cosa deve farci è
            praticamente impossibile
            accontentarlo.In pratica siamo del tutto d'accordo, io esagero un po' per evidenziare il punto. Non dico di andare per tentativi, ma dico di far vedere da subito al committente quello che ha richiesto, in modo di poter chiarire da subito cosa vuole davvero. Se invece di fargli vedere un software funzionante (ovviamente un prototipo, ma che renda l'idea) gli fai vedere un documento cartaceo condito da una bella spiegazione con termini tecnici, la tranvata la prendi il giorno del collaudo.Poi con una bella progettazione il giorno del collaudo avrai ottime ragioni a dire che il software fa esattamente quello che era stato pattuito. Non c'e' dubbio... ma nel frattempo il collaudatore non e' piu' il committente originario (e' passato troppo tempo) e avra' buon gioco ad affermare che tu come progettista non avevi capito nulla e comunque le carte le ha firmate uno che magari non e' neanche piu' in azienda. Magari puoi intentare una bella causa ma con quel cliente hai chiuso.
          • shevathas scrive:
            Re: alcuni motivi del disastro...

            Poi con una bella progettazione il giorno del
            collaudo avrai ottime ragioni a dire che il
            software fa esattamente quello che era stato
            pattuito. Non c'e' dubbio... ma nel frattempo il
            collaudatore non e' piu' il committente
            originario (e' passato troppo tempo) e avra' buon
            gioco ad affermare che tu come progettista non
            avevi capito nulla e comunque le carte le ha
            firmate uno che magari non e' neanche piu' in
            azienda. Magari puoi intentare una bella causa ma
            con quel cliente hai
            chiuso.è un doppio caso di malafede. Da parte della SH che cerca di ricorrere a cortine fumogene per mascherare il proprio deficit di analisi e da parte del committente per rimangiarsi quanto a suo tempo firmato.
          • ciliani scrive:
            Re: alcuni motivi del disastro...

            è un doppio caso di malafede. Da parte della SH
            che cerca di ricorrere a cortine fumogene per
            mascherare il proprio deficit di analisi e da
            parte del committente per rimangiarsi quanto a
            suo tempo
            firmato.Tu cosi' parti dal presupposto che sono tutti dei cialtroni. In realta' purtroppo queste cose succedono in perfetta buona fede da una parte e dall'altra. Non puoi addebitare un deficit di analisi ad una SH che ha fatto approfonditi documenti progettuali dove magari ci sono anche i disegni delle schermate dei prodotti finiti; analisi che e' stata approvata e controfirmata con il sangue dal committente. Poi ricordati che il committente che collauda non e' in genere quello che ha firmato.Anche rischiare di inserire funzioni che il progettista sa perfettamente che ci vogliono ma che il committente non vuole e' in genere perdente. Se il progettista ci ha indovinato, buon per lui; se non ci ha indovinato verra' percosso duramente dal committente (e bisogna proprio essere tanto tanto presuntuosi per credere di sapere meglio del committente cosa voglia il committente "davvero")Ripeto, secondo me continuare a credere che sia possibile in assoluto e sempre fare analisi esaustive, e che se cio' non succede e' solo colpa dell'analista, e' un approccio ingenuo e giovanilistico. E che la storia ha dimostrato ampiamente come sbagliato. Bisogna escogitare altri metodi per ovviare a questo, altrimenti i sistemi informativi complessi continueranno ad essere sviluppati sforando i budget e i tempi e deludendo i committenti.Poi che ci siano tanti analisti incapaci e' vero: i progetti sbagliati ci sono e la colpa in quel caso e' dei progettisti.
          • gerry scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: shevathas
            è un doppio caso di malafede. Da parte della SH
            che cerca di ricorrere a cortine fumogene per
            mascherare il proprio deficit di analisi e da
            parte del committente per rimangiarsi quanto a
            suo tempo
            firmato.Tu e HappyCactus state ragionando da ingeneri, siete convinti che l'utente finale sappia cosa vuole e sappia esprimere i suoi desideri in maniera corretta.Questo in realtà è quasi sempre impossibile e persino io che ho sempre e solo progettato e programmicchiato per hobby sono arrivato a capirlo.In generale comunque adesso in università ti spiegano che progettare un sistema partendo dalle specifiche, progettando e realizzando tutto con un solo passaggio è abbastanza utopico. E io da parte mia sono abbastanza d'accordo.
          • shevathas scrive:
            Re: alcuni motivi del disastro...

            Tu e HappyCactus state ragionando da ingeneri,
            siete convinti che l'utente finale sappia cosa
            vuole e sappia esprimere i suoi desideri in
            maniera
            corretta.
            Non è detto: il lavoro di un buon analista è anche il tirar fuori dal cliente quello che vorrebbe realmente. Ovviamente per fare ciò il cliente deve essere partecipativo e collaborare con il gruppo di sviluppo. Se il cliente non collabora allora è impossibile accontentarlo.Ci può essere malafede da parte della SH quando fa firmare cartaccia che convince il cliente che le sue esigenze sono soddisfatte da quello che la SH ha in pentola.Ci può essere malafede da parte del cliente quando dopo aver firmato a pera cerca di rimangiarsi tutto e scaricare su altri la responsabilità.Ho visto entrambi i casi, e spesso.
          • Aggiungitor e scrive:
            Re: alcuni motivi del disastro...
            Vorrei aggiungere una cosa.Va bene che in grandi progetti non si possono conoscere tutte le esigenze dall'inizio.Va bene che le esigenze (o altri fattori determinanti) nel tempo possono cambiare.Ma mi volete spiegare che cosa c'entra questo con il portale italia o quello dei certificati medici?In uno mancavano i contenuti, nel senso che il committente non sapeva cosa voleva metterci in termini di informazioni e funzionalita' (e' come se io andassi da un architetto per farmi progettare una casa e, alla sua domanda di come io la voglia, gli dicessi "ma, dentro ci vorrei vivere", poi quello la progetta, la fa costruire e io non ci metto i mobili e ci passo di tanto in tanto per leggere il giornale dal balcone perche' continuo a vivere nella mia baracca abusiva).Nell'altro mi volete dire quali esigenze imprevedibili c'erano? A oggi esiste una procedura di gestione dei certificati medici per malattia, andava informatizzata quella (lo so, sto ipersemplificando), non bisognava inventarsi un mondo nuovo o scoprire nuove esigenze, perche' le esigenze c'erano gia' ed erano gia' coperte (in parte almeno) dalla procedura attuale.
          • ciliani scrive:
            Re: alcuni motivi del disastro...

            Ma mi volete spiegare che cosa c'entra questo con
            il portale italia o quello dei certificati
            medici?sono d'accordo, questi sono due casi di nessunissima complicazione progettuale
          • HappyCactus scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: ciliani
            l'universita' l'ho fatta molti anni
            prima di te. Questo non puoi saperlo.
            La progettazione va
            fatta, ovviamente, ma credi a me e' impossibile
            prevedere all'atto della progettazione tutto
            quanto sarebbe necessario. Ho scritto forse qualcosa di diverso?Ti invito a rileggere, con calma e meno supponenza, quello che ho scritto fino ad ora.Forse alla tua pluriennale e indimostrata esperienza sul campo non si accompagna una dovuta attenzione nel leggere quel che l'interlocutore scrive, e quindi, esprime soltanto quella prosopopea che tu gratuitamente affibbi agli altri.cheers ;-)
      • Ichigo scrive:
        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!"
        • HappyCactus scrive:
          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.
          • 1Informatic oComeAltri scrive:
            Re: alcuni motivi del disastro...
            PS: mi scuso per la pessima grammatica e gli errori... purtroppo avevo fretta ed ho scritto "a braccio" senza rileggere. Brrrrr.... che orrore. :-) scusate scusate
          • bubba scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: 1Informatic oComeAltri
            PS: mi scuso per la pessima grammatica e gli
            errori... purtroppo avevo fretta ed ho scritto "a
            braccio" senza rileggere.

            Brrrrr.... che orrore. :-) scusate scusatequoto "abbastanza" quello che hai scritto....(orrori grammaticali a parte eheh)Tieni conto pero' dell' effetto "storie da sala macchine"(*), presente ovunque. E TANTO anche in italia (nei succitati accenture, engineering) ma anche in bestie piu piccole... A me personalmente, d'istinto, mi vengono i brividi quando sento piu di 2 o 3 buzzwords... poi ,si, capisco, talvolta, tolto il terrore iniziale, effettivamente alcune di queste figure intermedie (tra il committente e il programmatore/sysadmin) servono...(*)http://www.soft-land.org/storie/index
          • Enterprise Profession al scrive:
            Re: alcuni motivi del disastro...

            Scrivere codice
            è manovalanzaSbagliatissimo. Vedi:http://punto-informatico.it/b.aspx?i=3082733&m=3083827#p3083827
          • HappyCactus scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: Enterprise Profession al

            Scrivere codice

            è manovalanza

            Sbagliatissimo. Vedi:

            http://punto-informatico.it/b.aspx?i=3082733&m=308Ti ho risposto là, spiegandoti il perché. Niente di più corretto, invece ;-)
      • Enterprise Profession al scrive:
        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.
        • HappyCactus scrive:
          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).
        • shevathas scrive:
          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.
    • ullala scrive:
      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!
    • lui scrive:
      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.
      • ciliani scrive:
        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"
        • pippO scrive:
          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 ;)
          • ciliani scrive:
            Re: alcuni motivi del disastro...

            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.Guarda che non ci riescono neanche gli psicanalisti con trent'anni di esperienza a capire cosa voglia davvero un essere umano.Poi fammi un fischio quando il committente ti vidima il progetto che lui non ha chiesto, ma che tu DAVVERO sapevi che DAVVERO volesse nel segreto del suo cuore.;-) scherzo un po', mi raccomando non prendete subito tutti d'aceto, che diamine!
          • pippO scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: ciliani

            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.

            Guarda che non ci riescono neanche gli
            psicanalisti con trent'anni di esperienza a
            capire cosa voglia davvero un essere
            umano.Vero, ma qui si (s)parlava di procedure ;)
          • gerry scrive:
            Re: alcuni motivi del disastro...
            - Scritto da: ciliani
            Poi fammi un fischio quando il committente ti
            vidima il progetto che lui non ha chiesto, ma che
            tu DAVVERO sapevi che DAVVERO volesse nel segreto
            del suo
            cuore.Ma guarda che il committente ti vidima sempre quello che vuole. E' solo che di solito quello che vuole non è quello che gli serve.comunque questa ci stà tutta: http://godaddy.infinitylimited.net/misc_media/Software_Treeswing.jpg
    • ciliani scrive:
      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
      • pippO scrive:
        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! ;)
      • shevathas scrive:
        Re: alcuni motivi del disastro...
        QUOTONE
      • lui scrive:
        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.
    • KaysiX scrive:
      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/
    • Mux scrive:
      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.
    • infa scrive:
      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.
    • elpro scrive:
      Re: alcuni motivi del disastro...
      In 2 parole:http://dilbert.com/strips/comic/2011-02-03/
  • shevathas scrive:
    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...
    • che pena scrive:
      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
  • HappyCactus scrive:
    Contro domanda (maieutica)
    Come mai per costruire un grattacielo occorre assegnare il progetto ad un professionista, mentre per progettare una struttura informatica no?
    • Andrea S scrive:
      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
      • Professore scrive:
        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...
    • che pena scrive:
      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...
      • HappyCactus scrive:
        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.
        • vik scrive:
          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.
    • rover scrive:
      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.
  • HappyCactus scrive:
    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.
  • Garlini Valter scrive:
    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 !
    • Anonym ous scrive:
      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
  • bilop scrive:
    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.
  • gioca90 scrive:
    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?
    • Professore scrive:
      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!
      • gioca90 scrive:
        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 :)
        • urrrr scrive:
          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...
          • si fa per parlare scrive:
            Re: centro
            il punto è qui.non solo i riflettori ma anche l'attenzione della politica gira intorno a quest'uomo.quindi prima se ne va lui meglio è che i riflettori illuminano altra XXXXX e ce ne è tanta.poi arrivano gli altri.gli altri che sono al pari probabilmente, o meglio, statisticamente faranno lo stesso e via di riflettori anche su di loro.se invece fossimo in uno stato serie la gente si vergognerebbe in particolar modo i berlusconiani (chi lo ha votato) e senza accendere nemmeno una candela (altro che riflettori) tutti compatti li manderemmo a casa.i successivi poi starebbero molto più attenti, altrimenti tutti compatti li prenderemmo a calci in cu|o anche a loro....ma sai siamo in italia e la politica e tipo le guerre che si sviluppano qui su PI tra apple e Ms e linux.questo è il vero problema dell'italia... il senso dei cittadini verso lo stato.è l'unico _VERO_ problemagli altri sono solo questioni tecnicamente risolvibili in tempi più o meno lunghi... ma a noi piace pensare che i problemi dell'italia sono i politici... in modo che non è colpa nostra oppure al limite è colpo di chi vota il politico sotto i riflettori in quel momentoe ce ne vantiamo pure"figurati se gli altri sono meglio ... hihihi"tipico di"windows ha un bug""ma anche linux""ma anche mac"peccato che la politica è la vita reale un sistema operatico è uno strumento che alla fine più di tanto non ci condiziona
          • si fa per parlare scrive:
            Re: centro
            perdonate gli errori... la foga fa brutti scherzi in oltre non vorrei si fraintendesse questa frasegli altri che sono al pari probabilmente, o meglio, statisticamente faranno lo stesso e via di riflettori anche su di loro.la riscrivogli altri che sono al pari probabilmente, o meglio, gli altri che statisticamente sono al pari faranno lo stesso e via di riflettori anche su di loro.
          • dont feed the troll/dovella scrive:
            Re: centro
            - Scritto da: si fa per parlare
            il punto è qui.
            ma a noi piace pensare che i problemi dell'italia
            sono i politici... in modo che non è colpa nostra
            oppure al limite è colpo di chi vota il politico
            sotto i riflettori in quel
            momento

            e ce ne vantiamo pure
            "figurati se gli altri sono meglio ... hihihi"
            tipico di
            "windows ha un bug"
            "ma anche linux"
            "ma anche mac"
            Quoto questa parte che condivido appieno.il problema NON sono i politici siamo noi e la nostra mentalità, pure la mia.Una mentalità volta a ritenere i problemi FUORI da noi :"è colpa dei politici", esattamente come hai detto "è colpa di microsoft" (o dei cantinari), come se non fossimo noi a votarli o non fossimo noi come utenti e clienti a non pretendere di + dai nostri fornitori da consumatori consapevoli.Ci piace dividerci e litigare tra di noi, quanndo l'unica vera contrapposizione dovrebbe essere tra noi e i nostri problemi.Ieri sentivo in radio uno "scherzo" in cui qualcuno diceva "ma se fanno la riforma della giustizia, io guadagno 1200 euro al mese invece che 900?". Analogamente se invece che Berlusconi, o Bersani o chi per loro, vanno a casa o al governo,per noi, che cambia?Non sono loro, d'altronde, che fanno il Paese, quello lo facciamo noi.Se qualcosa non va, e di cose che non vanno che ne sono un bel po', forse dovremmo guardarci allo specchio e chiederci dove stiamo sbagliando.
        • shevathas scrive:
          Re: centro
          da quotare integralmente.
Chiudi i commenti