Italian Function Point: i prezzi del software nella Pubblica Amministrazione

Dopo il tilt del computer centrale delle Poste di inizio giugno, molti si stanno chiedendo come sono stati spesi i soldi del mega appalto (150 milioni di euro) per il nuovo sistema informativo delle Poste. Probabilmente la risposta è che, per ottenere un sistema informativo davvero affidabile, le Poste avrebbero potutto,  e forse dovuto, spendere di più. Nelle gare al "ribasso sfrenato" che si fanno nella P.A., le vere vittime sono i lavoratori (spesso precari e supersfruttati) e la qualità delle forniture e dei servizi ICT. Nel caso delle Poste, il risultato dei "risparmi" è evidente: il sistema è rimasto in tilt per una settimana, producendo danni per milioni di euro.



Ma cosa c'entrano i Function Point con l'ICT nella P.A.?


Uno degli indicatori statistici che aiutano a capire quanto il settore ICT della Pubblica Amministrazione italiana sia in crisi è il prezzo medio del Function Point. Il Function Point è l'unità di misura del software, un pò come i metri quadri sono l'unità di misura della superficie. La maggior parte dei software applicativi, soprattutto in ambiente bancario (Conti Correnti, Titoli ecc.) hanno  misure che vanno da 500 a 4000 Function Point ed oltre.

Le misure in Function Point sono molto usate nelle gare "al ribasso" della P.A. (Ministeri, Enti Pubblici). Il ribasso si effettua sul prezzo a Function Point. Stando ai dati forniti da Capers Jones, uno dei guru del Function Point, nel 2010 il prezzo medio a Function Point, nei paesi occidentali, non è mai stato inferiore a 200-300 dollari. Per applicazioni particolarmente complesse (software militare, ecc.) si è arrivati anche a 700-800 dollari a Function Point.



La bolla dei Function Point nella P.A.

In Italia, grazie alle gare "al ribasso" senza controlli sulla qualità effettuate dalla P.A., molte società si aggiornano gare di fornitura software con prezzi anche inferiori ai 100 euro a Function Point, invece dei 200-300 degli altri paesi occidentali. La sensazione è che i fornitori di software vincano le "gare" della P.A. offrendo prezzi eccessivamente bassi, per poi "piazzarsi" dal fornitore e ricattarlo dicendogli che, se vuole software funzionante, deve pagare di più. Questo tipo di meccanismo è presente in tutti i tipi di gare al ribasso della P.A. (servizi, costruzioni, ecc.). E' lo stesso tipo di meccanismo che permette alle ditte infiltrate dalla mafia di vincere appalti di costruzioni di strade e ponti offrendo prezzi ridicoli, per poi costruire i piloni con la sabbia al posto del cemento. Oppure gonfiare i prezzi inventando "varianti in corso d'opera".

I Function Point sono una misura molto astratta, quindi è facile lasciarsi ingannare da fattori soggettivi. Spesso i Function Point di un'applicazione si misurano sulla base della sola documentazione di progetto, prima ancora che l'applicazione venga realizzata. E' un pò come misurare i metri quadri di un appartamento basandosi sulla  piantina del progetto. L'appartamento potrebbe non essere mai costruito, o potrebbe essere costruito in modo diverso da come descritto nella piantina. Inotre, per dirla tutta, solo pochi ritengono i Function Point una misura davvero attendibile dei costi del software. 



Punti deboli dei Function Point: l'apparente  soggettività del modello dei dati

In passato, almeno fino a 4-5 anni fa, i manuali standard di conteggio in Function Point non erano molto chiari. Ciò permetteva ai fornitori di software di realizzare conteggi estremamente "soggettivi", soprattutto per la parte relativa al modello dei dati. I Function Point si basano su un modello dei dati, il Modello Entità-Relazioni, che è molto astratto e sofisticato.  Per "gonfiare" i conteggi in Function Point è ad esempio possibile, usando veri e propri sofismi, inserire nel modello "Entità-Relazioni" delle "entità" inesistenti. Oppure rappresentare, nel modello "Entità-Relazioni", più volte le stesse "entità". Con i prezzi italiani, ad ogni "entità" in più corrispondono da 7 a 15 Function Pont in più, ovvero, assumendo 100 euro a Function Point, da 700 a 1500 euro in più.

Ad esempio, il conteggio iniziale in Function Point per l'applicazione Web SIOPE, realizzata da EDS nel periodo 2005-2006 per Banca d'Italia (qualche migliaio di Function Point) era stato effettuato con tecniche che oggi, alla luce delle attuali standard sui Function Point, apparivano perlomeno discutibili. Il conteggio iniziale dell'EDS (poi rivisto dopo trattative con i tecnici della Banca d'Italia) era basato su un modello dei dati "ipertrofico", con molte più entità rispetto a quelle effettivamente necessarie.

L'appalto per la realizzazione della procedura SIOPE era stato suddiviso in due tranche, affidate a società diverse: la Datamat aveva realizzato la parte di estrazione dei dati dai database Banca d'Italia, la EDS aveva realizzato la parte di presentazione dei dati agli utenti, basata su un'interfaccia Web.

La componente Web di SIOPE era tecnicamente complessa e costosa, e la misura in Function Point non era in grado di rendere questa complessità. Per rientrare nei costi, la EDS aveva presentato un conteggio in Function Point con un modello Entità-Relazioni "ipertrofico". Il conteggio in Function Point della componente SIOPE realizzata da Datamat, pur basato sullo stesso modello dei dati, sembrava molto più "sobrio".



"Punti deboli" dei Function Point: il problema della matrioska

Prima di effettuare il conteggio in Function Point di un'applicazione è necessario stabilire il limite, il confine esterno dell'applicazione. Un pò come prima di effettuare la misura in metri quadri di un appartamento è necessario delimitare, sulla piantina, i muri perimetrali dell'appartamento.


Uno dei punti deboli delle misure in Function Point attualmente usate nei contratti della P.A. è che esse non escludono, almeno in linea di principio, l'applicazione del "sistema della matrioska". Con questo sistema, è possibile misurare in Function Point non solo il confine esterno di un'applicazione, quello che vede l'utente finale  (come si fa di solito) ma anche le sue componenti più interne. In questo modo il conteggio finale può essere maggiorato anche del 50%.

Ad esempio alcune applicazioni mainframe IBM con interfaccia WebSphere (come l'applicazione GAIA, realizzata nel 2006 da Almaviva per Banca d'Italia) sono state misurate in Function Point usando il sistema del "doppio confine". Questo tipo di applicazioni hanno un'interfaccia esterna Web, per l'utente finale, e un'interfaccia interna Java. In molti casi tutte e due le interfacce, sia quella interna (Java) sia quella esterna (Web) sono state misurate, e pagate, in Function Point. Un pò come pagare una volta e mezza la stessa applicazione. Inutile dire che, dal momento che questo tipo di misure "sdoppiate" sono molto comuni in Italia, i prezzi del Function Point nella P.A. sono ormai scesi al di sotto di quelli dell'India.



SAP e Function Point: come i cavoli a merenda

Un discorso a parte meritano i conteggi SAP in Function Point. SAP è il più grande prodotto ERP (Enterprise Resource Programming) attualmente commercializzato. Si tratta di un immenso e costosissimo programma applicativo, composto da vari moduli (Contabilità, Gestione del personale ecc.) che fanno più o meno tutto ciò che un'azienda può desiderare. I moduli SAP sono adattabili alle esigenze dei clienti (ad esempio, modifica delle intestazioni dei report con il nome dell'azienda, modifica dei programmi di contabilità per esigenze normative interne, ecc.). Dal momento che SAP è un prodotto estremamente complesso, la personalizzazione (customizing), cioè l'adattamento del prodotto alle esigenze del cliente, è a sua volta un'attività complessa e costosa.

Molte aziende del settore pubblico (in particolare, l'ENEL e la Banca d'Italia) usano SAP da più di dieci anni. Si tratta infatti di un prodotto che offre "chiavi in mano" soluzioni costose e complesse (Contabilità, Gestione del personale ecc.) che sarebbe difficile realizzare con programmi "fatti in casa". Dal momento che le aziende del settore pubblico usano i Function Point per  misurare tutte le loro attività, è sorto il problema di stabilire un correlazione tra le attività di customizing SAP e i Function Point.

Probabilmente misurare il customizing SAP in Function Point è un pò come sommare le mele con le pere: probabilmente non c'è nessuna correlazione. Ciònonostante, vari diligenti "esperti di Function Point" della P.A. si sono attardati in spericolate speculazioni teoriche, e hanno pubblicato dettagliate tabelle con improbabili correlazioni tra Function Point e numero di tabelle SAP usate durante le attività di customizing. Nei documenti pubblicati ci sono addirittura termini di teoria dei grafi (alberi, foglie).

Gli esperti dell'ENEL hanno addirittura pubblicato le loro teorie in un libro. In Banca d'Italia, ancora adesso tutte le attività di customizing SAP sono basate sulla fantomatica correlazione tra customizing SAP e Function Point. Quest'idea era nata più di dieci anni fa, quando i Function Point erano, almeno in Italia, un "oggetto misterioso", e nessuno ancora aveva capito bene come usarli. Ora i Function Point (e soprattutto i loro limiti) sono ben conosciuti, ma nessuno vuole negare di aver sbagliato. Anche perchè, si sa, ammettere i propri errori è sempre rischioso. E così si va avanti, facendo finta di niente.



Function Point e tecniche di scarico delle responsabilità

Durante una conferenza svoltasi in Italia, nel 2010, qualcuno ha chiesto a Capers Jones, uno dei guru americani del Function Point, che effetti possono produrre i prezzi così bassi del Function Point in Italia. La risposta è stata immediata: "They will sue you. You will go to litigations". Cioè, nasceranno delle cause legali.

In effetti, i previdenti dirigenti della Banca d'Italia, che forse più delle cause legali temono le ispezioni interne da parte dei loro stessi ispettori, hanno messo su una struttura di controllo dei conteggi in Function Point "a prova di bomba". Un vero muro di gomma. Le verifiche di dettaglio sui conteggi in Function Point  vengono eseguite da un consulente esterno, che però non è uno specialista certificato di Function Point (nel settore dei Function Point esistono veri e propri esami di certificazione). Il consulente esterno riporta direttamente a funzionari Banca d'Italia, che però non hanno competenze specifiche sui Function Point. I funzionari riportano a loro volta a dirigenti con competenze specifiche sui Function Point, che però non verificano  i dettagli sui conteggi.

Inoltre, su ogni conteggio in Function Point vengono effettuati dei "controlli incrociati", eseguiti da funzionari specialisti di informatica Bankitalia scelti secondo criteri casuali. Ovviamente, in questo intreccio estremamente complesso tutti sono occupatissimi a seguire i dettagli, ma apparentemente non c'è nessuno che abbia il quadro generale. Tutto questo "spreco di intelligenza" può essere molto vantaggioso in caso di diatribe legali o ispezioni interne: sarebbe quasi impossibile, per chiunque, districare il groviglio di responsabilità.



L'"Italia peggiore" di Brunetta

Grazie alla gare al ribasso sfrenato del settore ICT della P.A., in Italia si sta verificando una situazione particolare: i lavoratori, precari o sottopagati (o tutt'e due) accettano stipendi ridicoli pur di lavorare. I fornitori di servizi software usano questi lavoratori per offrire ai committenti servizi a "giorno-uomo" a prezzi stracciati. Il prezzo eccessivamente basso del Function Point italiano è una spia di questa situazione. I tecnici informatici dei committenti della P.A. (ministeri, ecc.) subiscono questa situazione, e hanno tutto l'interesse a "gonfiare" i conteggi in Function Point per ottenere applicazioni funzionanti.

C'è da dire che solo pochi esperti di informatica ritengono il Function Point una misura davvero attendibile dei costi del software. Per molti, i Function Point sono solo una delle tante statistiche, uno dei tanti inutili "nice to have" del mondo del software.

Viceversa, molti sedicenti esperti di Function Points sono in realtà degli incompetenti. Pare che, dopo il proliferare di conteggi in Function Point decisamente poco credibili, un alto dirigente della P.A., sedicente esperto di Function Point, abbia dichiarato: "I Function Point sono un pò come la pelle de li cojoni. Dove la tiri, quella là va".  Altro che sofisticati modelli matematici! Forse la realtà è un pò più complessa. Ma siamo sicuri che, di fronte a una frase del genere, lo stesso Albert Einstein avrebbe detto: "Mei cojoni!".