L’indicazione, che peraltro il P.T. riprende da precedenti linee guida, si applica certamente allo sviluppo di software applicativo, e impone chiaramente:

• l’apertura delle soluzioni;
• l’uso di standard pubblici;
• l’accessibilità;
• l’interoperabilità.

Tutti questi punti fanno parte delle assunzioni alla base delle attività del Tavolo di lavoro, che quindi risulta coerente con il P.T. Si ritiene inoltre che l’uso di metriche per le caratteristiche di accessibilità, interoperabilità, ecc. possa consentire di declinare questa e altre indicazioni del P.T. in maniera più definita e meno generica (ad esempio sostituendo il requisito “massima interoperabilità” con “interoperabilità pari a 100% sulla scala …”).

Le API dovranno prevedere:

• tracciabilità delle diverse versioni, allo scopo di consentire evoluzioni non distruttive (versioning);
• documentazione coordinata con la versione delle API (documentation);
• gestione degli utilizzatori, in particolare autenticazione e autorizzazione (user management, authentication, authorization);
• limitazioni di utilizzo collegate alle caratteristiche delle API stesse e della classe di utilizzatori (throttling);
• tracciabilità delle richieste ricevute e del loro esito (logging e accounting), anche al fine della non ripudiabilità della comunicazione;
• un adeguato livello di servizio in base alla tipologia del servizio fornito (SLA);
• pubblicazione di metriche di utilizzo (analytics).

Le indicazioni che il P.T. fornisce sull’argomento API appaiono, allo stato, generiche. L’uso di metriche potrebbe renderle più efficaci e cogenti nella scrittura di capitolati per la realizzazione di API.

In particolare, le indicazioni del P.T. si potrebbero declinare meno genericamente utilizzando metriche di sicurezza, manutenibilità, usabilità.

Viceversa, le “metriche di utilizzo” cui si riferisce l’ultima frase non rientrano nel ambito del tavolo di lavoro.

Anche questa indicazione rafforza gli assunti iniziali del tavolo di lavoro, in particolare l’attenzione agli standard e alle best practice.

Vale la pena anche osservare che l’architettura ad API ha impatti sul conteggio delle funzionalità di un’applicazione da realizzare, in quanto le funzionalità già offerte da un’API non rientrano nel perimetro del conteggio, ma va invece tenuto conto delle chiamate verso le API stesse.

Le P.A. potranno utilizzare i seguenti strumenti di sviluppo messi a disposizione da AgID:

• un repository del codice sorgente, nel quale confluiranno le componenti open source utili alle P.A. e alla community;
• il catalogo delle API;
• documentazione tecnica.

Si ritiene che il repository del codice sorgente debba fornire, nella descrizione dei componenti, anche misure oggettive delle caratteristiche degli stessi, e pertanto debbano essere utilizzate metriche. Ad esempio, oltre la descrizione testuale di un componente, si dovrà riportare una misura della sua usabilità, della sua manutenibilità, della sua affidabilità, ecc.

Lo stesso discorso vale, come detto, per il catalogo delle API.

Le metriche citate in questa indicazione sono, appunto, metriche di progetto, mentre le metriche di cui si occupa il Tavolo di lavoro sono di prodotto.

Si tratta dunque di tematiche che riguardano più il monitoraggio dei progetti che lo sviluppo applicativo.

Si cita comunque il passaggio per l’attenzione data alle metriche di tipo oggettivo, di cui il PT raccomanda l’uso al posto di semplici questionari/rilevazioni.

Occorre definire un prodotto minimo utilizzabile dall’utente e i passi incrementali e successivi che consegneranno una a una le funzionalità richieste, fino al completamento dei lavori, possibilmente utilizzando metodologie agili.

I corrispettivi dovuti ai fornitori verranno erogati solo ed esclusivamente al completamento e alla verifica di ciascuno di questi passi. Si raccomanda, inoltre, che il prodotto venga reso disponibile agli utenti in modalità sperimentale, senza aspettare il completamento di tutti i passi, al fine di individuare quanto prima eventuali problemi, criticità o fattori di rischio.

Non si ritiene che l’uso di metriche del software sia incompatibile con i modelli di sviluppo iterativi (es. metodologie agili), o che possa inficiare in qualche modo la loro diffusione nella P.A.

Occorre semmai suggerire alle P.A., operativamente, l’uso più efficace delle metriche del software in progetti che prevedano cicli di sviluppo iterativi. In letteratura tecnica l’argomento è stato già trattato approfonditamente e con esempi concreti (i cicli di sviluppo iterativi, ricordiamolo, non rappresentano certo una novità).

Si prova qui nel seguito a sintetizzare le indicazioni prevalenti riscontrate sull’argomento:

• per quanto riguarda le metriche funzionali, e nello specifico i punti funzione IFPUG, in letteratura si suggerisce di trattare la prima iterazione come uno sviluppo (considerando nella stima/conteggio tutti gli elementi come ADD) e le successive iterazioni come interventi di manutenzione evolutiva (quindi conteggiando punti funzione ADD, CHG e DEL);
• alcune iterazioni potrebbero avere contenuto funzionale nullo, vale a dire non produrre alcun punto funzione. Ad esempio, le iterazioni potrebbero includere correzioni di difetti riscontrati in iterazioni precedenti, oppure interventi migliorativi di caratteristiche non funzionali (usabilità, prestazioni, ecc.). In questi casi sono necessarie metriche non funzionali per quantificare gli interventi e consentire – secondo l’indicazione del P.T. – l’erogazione di un corrispettivo al fornitore.

Quindi, operativamente si suggerisce di procedere in questo modo:

ITERAZIONE 1:

Si contano i PF di sviluppo e metriche non funzionali sul software rilasciato. Il risultato del conteggio determina quanto occorre pagare al fornitore.

ITERAZIONE N-ESIMA:

Si contano i PF di MEV, + metriche che quantifichino gli interventi di manutenzione non evolutiva (misurando quanto si è alzata la qualità del software oggetto degli interventi). Il risultato del conteggio determina quanto occorre pagare al fornitore.

Non si condivide l’affermazione secondo cui effettuare misurazioni (funzionali e non funzionali) a ogni iterazione renderebbe “meno snello e veloce” e dunque inficerebbe i vantaggi del processo iterativo. Bisogna infatti considerare che a ogni iterazione si misura solo la porzione di software che è stata rilasciata, che per definizione è limitata e circoscritta. Misurare solo la porzione di software dovrebbe risultare molto meno laborioso di una misura dell’applicazione nel suo insieme.

Semmai potrebbero essere presi in considerazione, in cicli di sviluppo iterativi, strumenti automatici o metodologie semplificate per la stima e il conteggio della grandezza (funzionale e non) del software.

Occorre tener presente che l’uso delle metriche deve essere coerente e consistente. Occorre, all’inizio del progetto, scegliere le metriche adatte al caso specifico e, in seguito, avere l’accortezza di utilizzare sempre le stesse metriche al fine di ottenere, a ogni iterazione, risultati coerenti.