AFP e AEFP – Strategie di conteggio con gli Automated Function Point per la gestione dei Fornitori – Seconda Parte

By on
 

La gestione degli effort nei progetti di manutenzione evolutiva riveste oggi un’importanza strategica in quanto le odierne architetture software sono spesso sviluppate e manutenute da fornitori diversi (vendor). In altre parole, ci si può trovare di fronte a situazioni complesse, dove il conteggio dei Function Point Automatici dal codice sorgente non evidenzia un immediato riferimento con i requisiti utente funzionali espressi dal committente al vendor in fase di stima ex-ante (prima che il software sia stato progettato e sviluppato).

Nella fase di progettazione del software, quando è fondamentale identificare i budget da allocare per il progetto, spesso le stime ex-ante sono carenti o non documentate del necessario dettaglio; pertanto, dopo la fase di sviluppo del software (stime o misure ex-post) sarà necessario identificare sull’architettura i componenti da inserire nel perimetro di conteggio dei Function Point non preventivamente stimati.

Questa operazione viene comunemente effettuata con la cosidetta “perimetrazione e calibrazione”. Lo strumento che si utilizza è un vero e proprio “Calibratore di misura” che garantisce la corretta dimensione funzionale (e tecnica) allineando ciò che è stato “stimato” ex-ante con quello che è stato “misurato” ex-post dal codice sorgente applicativo (meglio quando il software è pronto per andare in esercizio). Questa modalità di conteggio automatica evidenzia anche quelle funzionalità che in fase di stima non è stato possibile preventivare per carenza di specifiche tecniche integrando nel conteggio questa carenza. Questo è possibile solo dopo lo sviluppo del codice e dopo che l’applicazione oggetto della misurazione degli AFP è stata analizzata automaticamente.

Nella prima parte dell'articolo abbiamo compreso che le “Transazioni complete” sono oggettive, perché implementate, cioè installate in ambiente di esercizio e non stimate. Abbiamo anche visto che le transazioni complete sono calcolate analizzando le funzioni presenti nei diversi livelli applicativi dell’architettura implementata.

Quindi, volendo fare un semplice esempio: se incontriamo una architettura in tecnologia J2EE composta da un livello di Presentazione (FrontEnd) per i dati che l’utente inserisce o preleva, un livello di Servizi (Service) per i dati che vengono ricevuti o inviati, un livello di Logica applicativa (Business) dove risiedono i dati che hanno valore per la specifica attività del committente e un livello per il disaccoppiamento della logica di persistenza (Data) che astrae la logica di accesso alle informazioni memorizzate sul database dal database fisico ed infine il livello fisico dei Dati (DB), la nostra “transazione completa”, per poter raggiungere il suo obiettivo di business, deve invocare nel suo “percorso” tutti i componenti che risiedono nei vari livelli, tipicamente a “cascata” in modo sincrono o asincrono dal livello di FrontEnd fino al DB.

Sappiamo con certezza, che le transazioni, essendo processi elementari, dovrebbero essere considerate sempre per il calcolo dei Function Point, che siano calcolati manualmente o automaticamente, come funzioni che si attivano dal FrontEnd e terminano nel Database (o strato fisico di persistenza).

Transazione completa AFPMa cosa succede quando ci viene presentata una situazione dove ciascun livello architetturale è assegnato contrattualmente per la manutenzione a fornitori differenti?
Mentre l’intera applicazione è di fatto in un unico progetto?
Nella sostanza la richiesta che spesso viene fatta dal Management Aziendale è quella di identificare e assegnare gli effort di manutenzione in termini di AFP suddividendoli per fornitore.

                                                                                                      Figura 1. Transazione completa (AFP)         

Qual è allora la risposta che può essere data in modo da garantire la corretta imputazione di AFP a uno specifico fornitore?
Dobbiamo ragionare considerando la transazione completa, ad esempio come quella rappresentata in Figura 1. Dal grafo si può capire che tale transazione attraversa i livelli applicativi ed è quindi possibile identificare dei “confini transattivi per layer” e impostare una suddivisione per livello applicativo come in Figura 2.

Figura 2. Transazione Completa suddivisa da Entry ed End Point (operazione di Split in Calibrazione)

Transazione completa suddivisa da Entry e End pointSe contrattualmente al Vendor 1 è assegnata la manutenzione del FrontEnd, mentre al Vendor 2 è assegnata la manutenzione del BackEnd (livello di logica applicativa),  è possibile identificare le funzioni in manutenzione ai diversi soggetti del contratto e tale ragionamento è ulteriormente iterabile come, per esempio in Figura 3, sull’ennesimo Vendor e l’ennesimo layer se esistente.

La modalità di split previsto dal metodo AFP consente di assegnare End Point a ciascun livello applicativo in modo tale che, nelle successive versioni analizzate in automatico per quel livello (perimetro), sarà possibile valutarne le modifiche intervenute nel corso del tempo in termini di elementi aggiunti, modificati, cancellati dai vari fornitori.  Una precisazione deve essere fatta quando si misurano gli effort in un progetto di manutenzione. Si deve sempre distinguere il valore “dimensionale” che identifica semplicemente la dimensione di ciò che risulta aggiunto, modificato, cancellato in termini di funzionalità utente, dal valore “patrimoniale” che  quella
manutenzione produce e che deve essere successivamente ponderato anche con altre misure di effort non misurabili tramite Function Point.Iterazioni e suddivisionei per Fornitore

La ponderazione automatica diretta tra AFP calcolato ed eventuale ponderazione con un'unità di costo potrà essere fatta solo dopo avere realizzato un certo numero di misurazioni tali da costruire un benchmark dove rilevare il fattore unitario con cui effettuare la ponderazione con il valore degli AFP e AEFP misurati.   

                                                                         

                                                                                                                 Figura 3 Iterazioni e suddivisioni per Fornitore (Vendor)

                                                                                                                                           

 

 
Custom social sharing