Size Estimation. Fig. 1: Metodologia Web Framework Points

Transcript

1 Calcolo della stima dell'effort di un'applicazione Web sviluppata mediante CMF In questo articolo presentiamo la metodologia sperimentale Web Framework Points (WFP), utilizzabile per la stima dell'effort di un'applicazione Web. WFP è stata realizzata congiuntamente dai dipartimenti DIEE (Università degli studi di Cagliari) e DITEN (Università degli studi di Genova). Essa è stata pensata per essere adottata su applicazioni Web sviluppate mediante Content Management Framework (CMF), indipendentemente dalla tecnologia con la quale sono implementati gli stessi framework. La metodologia si basa su due fasi distinte, che possono essere eseguite in parallelo, e su una fusione finale tra i dati provenienti da esse: Size Estimation: in questa fase si calcola la stima della dimensione dell'applicazione a partire dai requisiti, espressi come insieme di elementi. Cost Model Estimation: in questa fase, a partire dalle caratteristiche del team di sviluppo, si identifica lo sforzo necessario ad implementare i diversi elementi, in termini di tempo. Questa fase è relativa al team e non va ripetuta per ogni singolo progetto. Effort Estimation: dopo aver completato le due fasi, si otterrà la stima finale dell'effort dell'applicazione in termini di giorni-uomo. La seguente immagine (Fig.1) illustra sinteticamente la metodologia di calcolo dell'effort. Size Estimation Fig. 1: Metodologia Web Framework Points In seguito all'analisi di un campione di applicazioni Web, dove sono stati individuati degli elementi peculiari e ricorrenti, si è deciso di suddividere tali elementi in due insiemi: Elementi Generali e Funzionalità Specifiche. Ogni elemento individuato è caratterizzabile da un grado di complessità, che dipende da diversi fattori: contesto dell'applicazione, essere o no presente nella libreria del CMF utilizzato, eventuali personalizzazioni da apportare, riuso, ecc. La somma pesata dell'insieme degli elementi individuati costituisce la stima dimensionale (size estimate) dell'applicazione Web. In questo modo, la stima della dimensione avviene dal punto di vista delle funzionalità offerte dall'applicazione all'utente, come nella metrica classica Function Points" di Albrecht, includendo anche fasi di studio più generali e con il tutto contestualizzato alle attuali tecnologie. Come detto in precedenza, la classificazione prevede due gruppi: Elementi Generali e Funzionalità Specifiche. Gli Elementi Generali sono rappresentati da tutte le attività preliminari di analisi e progettazione e dagli elementi essenziali alla creazione della struttura portante di un'applicazione, come gli elementi grafici di base ed alcuni contenuti informativi, solitamente statici e con cui l'utente ha una interazione bassa o nulla. Appartengono a questa categoria anche le attività di studio del contesto e

2 di posizionamento dell'applicazione da utilizzare. Alcuni elementi sono singoli, mentre per altri esiste una molteplicità di elementi. Ma in entrambi i casi, bisogna mettere in relazione tutto ciò con il tempo necessario alla loro realizzazione. Nelle Funzionalità Specifiche, invece, rientrano tutti gli elementi necessari a rendere possibile la realizzazione delle funzionalità dell'applicazione. Si considerano le funzionalità create appositamente, e quindi definibili con un alto livello di personalizzazione e interazione con il database (autenticazione, profilazione, tabelle del DB, form di inserimento dati, ecc.). Anche in questo caso, le funzionalità sono valutate sia con il numero di elementi presenti che con il rispettivo livello di complessità, definito nel seguito. Le Tabelle 1 e 2 presentano la suddivisione specifica degli elementi ed una loro breve descrizione. Gli elementi singoli sono sempre generali, quelli multipli possono essere generali o funzioni specifiche. Elementi generali singoli Analisi del contesto e dell'utenza Analisi della domanda e dell'offerta online Definizione Analisi delle criticità e opportunità dello spazio informativo in cui si vuole inserire l'applicazione Web. Sintesi critica del posizionamento di mercato dell'applicazione da sviluppare e rassegna di materiali raccolti (indagini di mercato, interviste, focus group, ecc.). Produzione del logo e immagine coordinata Studio approfondito di grafica e del suo significato. Preparazione del mockup nudo, requisiti e navigazione Produzione del layout grafico Sistema di content management Trovabilità del sito e verifica del posizionamento Gestione e riaggregazione di metadati e chiavi Personalizzazioni a carico della redazione Content architecture Motore di ricerca generale del sito Infrastruttura sistemistica Newsletter Creazione testi, immagini, video ad hoc Mappa (o sfondo) Decisioni in merito a come si desidera che sia fatta la navigazione entro il sito, cosa si intende evidenziare, soluzioni di content management. Layout che viene elaborato dai grafici, a partire dal mockup nudo (Titolo, piè di pagina, elementi statici di interfaccia) Studio dei componenti per la gestione dei contenuti Operazioni legate al posizionamento del sito nei motori di ricerca Categorizzazione e classificazione dei contenuti e informazioni presenti nel sito Web. Possibilità di aggiornare il sito dall'esterno, nel caso in cui si preveda una conduzione a carico dello stesso sviluppatore del sito Progettazione della gestione dei contenuti: tipologia di documenti e il tipo di gestione desiderata Motore di ricerca di base (standard) o personalizzato presente nell'applicazione. Predisposizione all'infrastruttura necessaria a livello di sistema. Politiche di diffusione e pubblicazione dei contenuti, ogni quanto tempo, a chi inviare, ecc. Sviluppo di contenuti multimediali originali per il Web su richiesta del committente su argomenti specifici Gestione sfondi necessari alla creazione di eventuali informazioni geo-referenziate nell'applicazione Tabella 1: Elementi generali singoli

3 Elementi Generali Elementi multipli Community e social management Template del sistema di navigazione Gestione ruoli utenti Multilinguismo Gestione aree riservate Definizione Collegamento della propria applicazione Web coi principali social network. La gestione della presenza può essere statica o dinamica Progettazione dei template principali. Registrazione utenti front-end e personalizzazione del tipo di accesso al sito a seconda del tipo di utente. Traduzione semplice del sito e ri-progettazione di alcune parti a seconda della lingua Definizione livelli di accesso e funzionalità di ogni area riservata, rappresentata da pagina o sezione del sito. Funzionalità Specifiche Progettazione sistema di report Creazione DB e Query interna Tipi di file gestiti dall'applicazione Accessi a sistemi esterni Servizi resi disponibili all'esterno dell'applicazione Query esterna Base dati cartografica Creazione e inclusione di mappe personalizzate Report semplici e complessi Si considera il numero di tabelle del DB Si considerano i diversi tipi di file che l'applicazione deve gestire Si considerano le applicazioni esterne con cui il sistema deve interagire. Web services offerti dal sistema Interrogazioni a DB esterni all'applicazione Utilizzo e gestione di basi dati pre-esistenti necessarie ad includere informazioni geo-referenziate nell'applicazione Le basi dati cartografiche realizzate ad-hoc rientrano nella categoria creazione DB e query esterne. Creazione ed inclusione di mappe dotate di icone segnaposto, linee, strumenti di selezione, video o immagini, ad esempio attraverso l'utilizzo di API Google Maps JavaScript. Moduli di input /output dati Mappe cliccabili Moduli specifici dell'applicazione per l'input/ output dei dati (di solito sono input form) Immagini/grafici dotati di collegamenti ipertestuali verso altri siti o ad altre sezioni dello stesso sito. Tabella 2: Elementi multipli

4 Cost Model Estimation In questa fase si analizzano le caratteristiche del team di sviluppo (esperienza, skill, tecnologie utilizzate, riuso, ecc.) al fine di determinare, per ciascun elemento individuato dalla metodologia, l'effort necessario alla sua implementazione ed individuare in questo modo il Cost Model relativo al team. Come in molte altre metodologie di stima, l'effort è espresso in giorni-uomo. È importante sottolineare che la valutazione è basata esclusivamente sulle qualità e capacità di lavoro del team, in riferimento a casi analoghi precedentemente affrontati (analogy-based estimation). Per determinare il Cost Model relativo ad un team si esprime, per ciascun elemento, l'effort necessario per svolgere quell'operazione (ad esempio, l'analisi del contesto e dell'utenza può essere svolta in n giorni). Il valore che esprime l'effort per ogni singola voce non è univoco, ma dipende dal grado di difficoltà attribuito alla stessa. Si è deciso di usare quattro livelli per valutare la complessità. Ciò perché quattro è un numero sufficientemente elevato di livelli, e perché, essendo pari, impedisce di avere un livello neutro centrale (non facile né difficile). Ogni team ha il proprio Cost Model, che è rappresentativo dei valori da esso messi in campo. È possibile, inoltre, che nella stessa azienda siano presenti più team, ed in questo caso è logico attribuire diversi valori di effort in funzione delle risorse a disposizione. Il grado di complessità da attribuire alle attività di analisi, progettazione e sviluppo è fortemente legato al contesto ed alla dimensione dell'applicazione, esso è dunque da valutare su base empirica. Per quanto riguarda le attività di sviluppo, consideriamo: Complessità bassa quando l'elemento è presente nella libreria del CMF o quando si utilizzano elementi preesistenti senza effettuare modifiche sostanziali (elevato grado di riuso); Complessità medio/bassa quando l'elemento è presente nella libreria del CMF ma è necessaria una sua personalizzazione o quando si utilizzano elementi preesistenti con modifiche non sostanziali (grado di riuso medio-alto); Complessità medio/alta quando l'elemento non è presente nella libreria del CMF ed è dunque necessario implementarlo utilizzando un breve periodo di tempo oppure quando la personalizzazione di un elemento presente in libreria è complessa (grado di riuso medio/basso). Complessità alta quando l'elemento non è presente nella libreria del CMF ed è dunque necessario implementarlo oppure quando la personalizzazione di un elemento presente in libreria è molto complessa (basso grado di riuso). Nella Tabella 3 sono riportati come esempio i valori di effort di una selezione di elementi in riferimento ad un'azienda che ha collaborato durante il periodo di sperimentazione della metodologia: Complexity degree [man-days] Element Low Medium- Low Mediumhigh High Context and user-base analysis Analysis of on-line demand-and-offer Newsletter Customizations by editorial staff Site findability and positioning verification Content architecture Management and re-aggregation of tags and keys System infrastructure Tabella 3: Cost Model Team A (tabella parziale)

5 Si può notare come ogni voce abbia il proprio livello di difficoltà (definito dall'azienda in questione), il quale concorre alla determinazione del valore di stima finale del progetto, espresso naturalmente in giorni-uomo. Dalla sperimentazione della metodologia Web CMF Object sono stati ricavati quattro Cost Model tipici, utilizzabili per preventivare l'effort dei progetti relativamente a quattro categorie di team di sviluppo: Sviluppatore freelance / Micro Azienda, Azienda Piccola, Azienda Media e Azienda Grande. In questo modo qualunque tipo di team che utilizzi CMF per sviluppare le proprie applicazioni può utilizzare immediatamente la metodologia WFP. Effort Estimation Dopo aver completato le due fasi di Size Estimation e Cost Model Estimation, si è in possesso di tutti gli elementi per procedere al calcolo della stima dell'effort del progetto espressa in giorni-uomo. La stima finale è data dalla somma pesata degli elementi presenti nell'applicazione Web: ogni elemento trovato in fase di analisi infatti ha un proprio valore di effort espresso in giorni-uomo e una propria numerosità; la moltiplicazione di ciascun elemento con il proprio valore di complessità e la successiva somma forniscono l'effort complessivo dell'applicazione Web esaminata. Il risultato è riassuntivo di tutte le operazioni descritte fino a questo punto; esso dovrà essere confrontato al termine del progetto con l'effettivo numero di giorni utilizzati per arrivare all'effort definitivo. Ogni singola voce è controllabile, ovvero è possibile verificare dove si è preventivato un numero inferiore (o superiore) di giorni-uomo tale per cui si sia verificato un errore di pianificazione. Durante la fase di sperimentazione, è stata valutata l'efficacia della metodologia nella previsione dell'effort nelle applicazioni Web fornitaci dalle aziende che hanno partecipato al progetto. Attraverso il calcolo del MRE, una misura comunemente utilizzata in letteratura per misurare l'accuratezza dei modelli di previsione, è stata svolta un'operazione di confronto tra i valori di effort a preventivo ottenuti dall'applicazione della metodologia Web Framework Points con i valori di effort reali a consuntivo, cioè l'effort effettivamente speso per ciascun progetto. L'MRE misura l'errore relativo della previsione rispetto al valore reale. I valori suggeriti in letteratura per la soglia di accettabilità di una metodologia di previsione sono i seguenti: dato un insieme di progetti, almeno il 75% delle previsioni effettuate su di essi non deve superare un valore di MRE pari al 0,25. Questo vuol dire che una metodologia accettabile deve essere in grado di effettuare previsioni di effort con un errore inferiore al 25% in più del 75% dei casi. Come risultato, è emerso che la metodologia WFP ha preventivato l'effort di ciascun progetto con un valore di MRE inferiore a 0,25 nel 100% dei casi studiati, quindi essa soddisfa a pieno i criteri previsti in letteratura. Tool Web Framework Points (versione beta) Cliccando sul seguente Link, è possibile accedere all'applicazione interattiva Web Framework Points (WFP) per stimare l'effort richiesto per sviluppare applicazioni Web, basata sulla metodologia appena descritta, dove è possibile trovare anche la guida al suo utilizzo. La metodologia sperimentale 1 è descritta nel dettaglio nei seguenti articoli (gli articoli sono disponibili, sul sito BOMEC): Corona E., Concas G., Marchesi M., Barabino G., Grechi D., Effort Estimation of Web 1 Il nome con cui originariamente la metodologia è stata sinora presentata nella produzione scientifica è Web CMF Objects; in seguito è stata rinominata Web Framework Points

6 Applications through Web CMF Objects, The Joint Conference of the 22nd International Workshop on Software Measurement (IWSM) and the 7th International Conference on Software Process and Product Measurement (MENSURA) October 17-19, 2012, Assisi, Italy Erika Corona, Michele L. Marchesi, Giulio Barabino, Daniele Grechi, and Laura Piccinno, Size Estimation of Web Applications through Web CMF Object, 3rd International Workshop on Emerging Trends in Software Metrics (WETSoM 2012) 3 June Zurich, Switzerland