IT: l’analisi indipendente

To err is human, but to really foul things up you need a computer.

– Paul Ehrlich

Come ci ha insegnato Steve McConnell sul suo Code Complete, le attività di costruzione di un progetto software dovrebbero essere condotte ordinatamente ed in modo completo per evitare gli ormai classici e famosi disastri, o anche quelli più vicini a casa nostra.

Con particolare riferimento alle prime fasi di un progetto informatico, si nota [Boehm – Papaccio – Understanding Software Costs] che maggiore è la distanza tra la fase progettuale in cui un difetto viene rilevato/identificato e la fase in cui viene determinato, cioè l’errore che c’è a monte e che ha prodotto il difetto, è esponenzialmente proporzionale al costo della risoluzione del difetto.

Quindi si deduce che le attività di studio di fattibilità ed analisi dei requisiti, sono le fasi le cui carenze pesano maggiormente sui costi finali dei progetti, anche informatici.

Oggi nessuno potrebbe pensare di affrontare la costruzione di un edificio che sia più complesso di un’aia per galline, senza un’opportuna fase di studio ed analisi. Eppure nel campo dell’informatica persiste ancora questa deprecabile abitudine.

Un modo che trovo possa essere efficace per rimuovere questo ostacolo è quello di autoregolamentarsi per eliminare il conflitto di interessi che oggi c’è tra analista e sviluppatore.

Oggi il tipico provider di soluzioni informatiche, piccolo o grande, offre lo studio di fattibilità, l’analsi, lo sviluppo e il collaudo della soluzione informatica; c’è un discreto conflitto di interessi nelle attività elencate, infatti:

  • quasi sempre lo studio di fattibilità indicherà che il progetto è fattibile e che proprio questo solution provider ha la soluzione
  • l’analisi mostrerà che la soluzione appropriata è quella che il solution provider ha già fornito anche ad altri clienti

Ovviamente non è affatto detto che le due affermazioni sopra siano sempre false né che siano sempre vere. Ciò che è vero è che spesso anche se il progetto fallisce, il solution provider è comunque e giustamente da pagare per il lavoro svolto.

Lo studio di fattibilità, l’analisi e specifica dei requisiti, così come la direzione dei lavori e il collaudo finale dell’applicazione informatica dovrebbero essere sempre condotti con un “capitolo di spesa” diverso da quello utilizzato per la produzione vera e propria della soluzione informatica.

Quindi un’organizzazione che ha a cuore l’efficacia dei suoi investimenti dovrebbe autoregolamentarsi in tal senso adottando un processo di acquisizione dei beni IT che comprenda:

  • lo studio di fattibilità
  • l’analisi dei requisiti e la loro specifica
  • la redazione di un capitolato di gara per l’assegnazione dei lavori e l’identificazione di un produttore di software adeguato sia sotto il profilo economico che qualitativo
  • la nomina di un responsabile per la direzione dei lavori e per il collaudo finale

Oggi quante organizzazioni hanno un processo di acquisizione di beni IT di questo tipo? E quante di quelle che spendono soldi pubblici possono dire di averci anche solo pensato alla formalizzazione di un processo strutturato di acquisizione? Purtroppo poche…

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...