Calcolo della stima dell'effort di un'applicazione Web sviluppata mediante CMF
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
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.
Fig. 1: Metodologia Web Framework Points
Size Estimation
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 edi 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 Definizione
Analisi del contesto e dell'utenza Analisi delle criticità e opportunità dello spazio informativo in
cui si vuole inserire l'applicazione Web.
Analisi della domanda e dell'offerta online 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 Decisioni in merito a come si desidera che sia fatta la
navigazione navigazione entro il sito, cosa si intende evidenziare, soluzioni
di content management.
Produzione del layout grafico Layout che viene elaborato dai grafici, a partire dal mockup
nudo (Titolo, piè di pagina, elementi statici di interfaccia)
Sistema di content management Studio dei componenti per la gestione dei contenuti
Trovabilità del sito e verifica del Operazioni legate al posizionamento del sito nei motori di
posizionamento ricerca
Gestione e riaggregazione di metadati e Categorizzazione e classificazione dei contenuti e informazioni
chiavi presenti nel sito Web.
Personalizzazioni a carico della redazione Possibilità di aggiornare il sito dall'esterno, nel caso in cui si
preveda una conduzione a carico dello stesso sviluppatore del
sito
Content architecture Progettazione della gestione dei contenuti: tipologia di
documenti e il tipo di gestione desiderata
Motore di ricerca generale del sito Motore di ricerca di base (standard) o personalizzato presente
nell'applicazione.
Infrastruttura sistemistica Predisposizione all'infrastruttura necessaria a livello di sistema.
Newsletter Politiche di diffusione e pubblicazione dei contenuti, ogni
quanto tempo, a chi inviare, ecc.
Creazione testi, immagini, video ad hoc Sviluppo di contenuti multimediali originali per il Web su
richiesta del committente su argomenti specifici
Mappa (o sfondo) Gestione sfondi necessari alla creazione di eventuali
informazioni geo-referenziate nell'applicazione
Tabella 1: Elementi generali singoliElementi multipli Definizione
Community e social management Collegamento della propria applicazione Web coi principali
social network. La gestione della presenza può essere statica o
dinamica
Template del sistema di navigazione Progettazione dei template principali.
Elementi Generali
Gestione ruoli utenti Registrazione utenti front-end e personalizzazione del tipo di
accesso al sito a seconda del tipo di utente.
Multilinguismo Traduzione semplice del sito e ri-progettazione di alcune parti a
seconda della lingua
Gestione aree riservate Definizione livelli di accesso e funzionalità di ogni area
riservata, rappresentata da pagina o sezione del sito.
Progettazione sistema di report Report semplici e complessi
Creazione DB e Query interna Si considera il numero di tabelle del DB
Tipi di file gestiti dall'applicazione Si considerano i diversi tipi di file che l'applicazione deve
gestire
Accessi a sistemi esterni Si considerano le applicazioni esterne con cui il sistema deve
interagire.
Servizi resi disponibili all'esterno Web services offerti dal sistema
Funzionalità Specifiche
dell'applicazione
Query esterna Interrogazioni a DB esterni all'applicazione
Base dati cartografica 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 e inclusione di mappe Creazione ed inclusione di mappe dotate di icone segnaposto,
personalizzate linee, strumenti di selezione, video o immagini, ad esempio
attraverso l'utilizzo di API Google Maps JavaScript.
Moduli di input /output dati Moduli specifici dell'applicazione per l'input/ output dei dati (di
solito sono input form)
Mappe cliccabili Immagini/grafici dotati di collegamenti ipertestuali verso altri
siti o ad altre sezioni dello stesso sito.
Tabella 2: Elementi multipliCost 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 Medium- Medium-
Low High
Low high
Context and user-base analysis 0.5 1 2 5
Analysis of on-line demand-and-offer 0.5 1 3 5
Newsletter 0.5 2 4 6
Customizations by editorial staff 0.5 1 5 8
Site findability and positioning verification 0.5 1 2 3
Content architecture 0.5 1 2 3
Management and re-aggregation of tags and keys 0.5 1 1.5 2
System infrastructure 1 2 3 5
Tabella 3: Cost Model Team A (tabella parziale)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 sperimentale1 è 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 PointsApplications 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 2012 - Zurich,
SwitzerlandPuoi anche leggere
