I Wiki e il controllo qualità del software
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
I Wiki e il controllo qualità del software Uno strumento online di scrittura collaborativa Ercole Colonese, Consulente e socio Aicq Felice Del Mauro, Direttore tecnico iStream. Pubblicato su Qualità, N. 1 2012 Sommario L’adozione di metodologie e standard per la produzione del software da parte di piccole organizzazioni - ad esempio quelle definite con meno di 25 elementi e denominate VSE (Very Small Enterprises) in ISO/IEC TR 29110 Software engineering, Lifecycle profiles for Very Small Entities - si scontra puntualmente con le esigenze di flessibilità da un lato e con la mancanza di risorse infrastrutturali e di presidi metodologici dall’altro. Questa mancanza fa si che anche i tentativi di adozione, magari sulla spinta di un progetto, non riescano a sopravvivere, nella loro applicazione, ai progetti stessi, e l’organizzazione si ritrovi spesso a reiterare tali iniziative. Per il superamento di queste difficoltà, un ruolo essenziale è ricoperto dall’uso di strumenti che facilitino la diffusione della cultura degli standard e delle metodologie e che si presentino con la facilità d’uso e la flessibilità, che consentano cioè un uso quasi “personale” dei dati, dei software di produttività individuale tipo “Office”. D’altro lato rispetto all’uso personale dei documenti, un aspetto metodologicamente importante nella gestione della qualità, la cui rilevanza cresce con il tempo, è la “collaborazione e condivisione” del lavoro e delle informazioni durante l’ideazione e progettazione di un prodotto, ed il fiorire di numerosissime soluzioni quali Blog, Wiki, Forum etc. di uso sempre più crescente in ambito tecnico ne è la testimonianza. Le caratteristiche di gratuità, accessibilità, facilità d’uso anche per personale non specializzato, forniscono alle nuove piattaforme tecnologiche citate una valida chance per rappresentare una possibile soluzione al problema dell’adozione delle metodologie se impiegati nei processi operativi e di controllo del ciclo di vita del software. Nell’articolo si riportano i risultati di una sperimentazione effettuata mediante un prototipo di applicazione che utilizza i Wiki di ultima generazione per gestire i Requisiti e i Casi D’uso all’interno del ciclo di vita più “snello” dello standard in ISO/IEC TR 29110 per le piccole organizzazioni. La gestione dei Requisiti del prodotto, e successivamente degli Use Case, nelle loro specifiche caratteristiche di elementi informativi semistrutturati che devono essere compresi, integrati, catalogati e validati, è fatta secondo moduli molto flessibili che possono essi stessi integrati dagli utenti per incorporare nuove informazioni e quindi, con il contributo di una pluralità di soggetti, convergere verso una forma completa e stabile (definitiva). Le recenti tecnologie software, nel caso di quest’applicazione le tecnologie legate al Web Semantico, offrono crescenti opportunità per superare le barriere di natura organizzativa legate all’introduzione di metodologie e standard; in tale contesto lo strumento dei Wiki potrà sicuramente trovare proficui ambiti per applicazioni di successo nel Software Engineering e la Gestione della Qualità
I wiki e il controllo qualità del software
A che punto è il progetto rispetto agli obiettivi?
Il contesto
Quali requisiti o caratteristiche sono stati
I sistemi di qualità nelle aziende di software analizzati finora?
manifestano il duplice aspetto di apparente Quali componenti sono stati codificati e
necessità e di inutile vincolo. Come descritto testati? Quali sono ancora in fase di sviluppo?
nell’articolo menzionato in bibliografia [1], Come si prevede di testare le funzionalità?
l’applicazione dei sistemi ISO 9001 è stata e spesso Quali sono i risultati del test eseguiti finora?
tuttora è una pratica onerosa soprattutto a causa Quali sono i problemi ancora aperti?
della mole di documentazione generata.
Il problema della documentazione pone due
diverse considerazioni:
Quanto è utile e funzionale all’esecuzione dei
processi tecnici di produzione la
documentazione necessaria e prevista dal
sistema di qualità?
Quanto è aggiornata con i documenti “vivi”
utilizzati dagli attori del processo (progettisti,
sviluppatori, manutentori etc.) di sviluppo
software la documentazione prodotta per il
sistema di qualità?
Figura 1 - Form per l’inserimento dei requisiti
Il problema che si affronta nell’articolo è quello
relativo all’utilizzo di una nuova e versatile forma
di documentazione e di condivisione della
Il Wiki come architettura della soluzione
conoscenza costituita dalla tecnologia dei Wiki Volendo riassumere in un’unica frase la definizione
come veicolo per la realizzazione di applicazioni a di un classico Wiki si può dire che esso è uno
supporto della qualità nello sviluppo software. strumento online di scrittura collaborativa in cui
Si osserva come le capacità di attrarre interesse e ciascuno può aggiungere nuovo contenuto o
sviluppare forme spontanee di collaborazione nelle modificare quello esistente e pubblicato [7].
fasi di ideazione e progettazione dei prodotti sia un Le funzioni di base che un autore può utilizzare sui
formidabile fattore di competitività e di sviluppo in Wiki sono:
una economia sempre più aperta e paritaria [1].
Creare un articolo1 su un tema d’interesse;
In quest’ottica, lo strumento del Wiki, oltre a Integrare o Modificare gli articoli scritti da altri;
quello dei Blog, sta guadagnando una crescente Creare collegamenti (link) tra articoli,
fiducia nelle comunità degli utenti per la sua raggrupparli in categorie etc.
facilità d’uso.
La caratteristica fondamentale di questi strumenti
Nell’industria del software il Wiki, introdotto è la possibilità di scrivere, usando il proprio
inizialmente come strumento di documentazione browser e senza dover conoscere il relativo
tecnica del prodotto, può essere utilizzato come linguaggio (es.: HTML), articoli contenenti elementi
strumento di gestione e controllo del processo diversi, quali ad esempio, immagini, tabelle e link,
produttivo, grazie alle sue recenti evoluzioni. In che vengono visualizzati come pagine web. Questa
questo modo si possono trasferire ad altri ambiti le facilità consente ad un grande numero di utenti
caratteristiche di flessibilità e aderenza verso la (non solo sviluppatori, esperti delle tecnologie e
realtà operativa che lo caratterizzano.
Qui di seguito è illustrato un utilizzo del Wiki, nelle 1
Il termine “articolo”, nato in origine per indicare una
sue forme più recenti, come strumento di Quality pubblicazione sulla Rete, indica, in questo contesto la
Assurance delle fasi iniziali del processo di sviluppo scheda descrittiva di un elemento del processo, come
del software che consente di rispondere alle un requisito, un caso d’uso, una specifica etc., un
domande che si pongono nel corso della programma etc. Un Documento dei Requisiti o
realizzazione: Documento di Specifiche è composto assemblando tutti
gli articoli a lui inerenti
2
I wiki e il controllo qualità del software
dei linguaggi di programmazione, ma anche utenti aggiornate dei dati primari e che possono
non esperti) di condividere informazioni su ogni essere personalizzate anche da chi non
argomento, di collaborare nell’ambito di processi possiede conoscenze di programmazione.
collettivi di produzione di conoscenza, come i Presentazione visuale delle informazioni con i
progetti di sviluppo software, e di accumulare una dati semistrutturati mostrati in forma di grafici,
grande mole di informazioni sempre a disposizione mappe semantiche, calendari e altro, fornendo
per la consultazione. una panoramica più ricca di quella restituita
dalle semplici liste.
La tecnologia dei Wiki, si è evoluta, nella sue
Moduli costruiti “al volo” per un inserimento
funzionalità di base limitata alla produzione di
guidato delle informazioni. Le estensioni Halo
testo “libero”, ossia senza struttura, da parte degli
permettono ad un utente di definire delle form
utenti, verso una seconda generazione detta
per l’inserimento dei dati senza avere in back-
”Enterprise Wiki” o “Structured Wiki” che
end uno schema di Database e quindi
presenta, in aggiunta alle caratteristiche
rendendo il ciclo di progettazione-
precedenti, nuove funzionalità che fanno del Wiki
realizzazione-acquisizione di dati molto più
una piattaforma per lo sviluppo di applicazioni
rapido che nelle applicazioni tradizionali.
quali:
Rispetto all’usuale approccio “Top Down” dei
Event Tracker (Sales Pipeline Tracker, Trouble
sistemi di Content Management che propongono
Ticketing etc.);
schemi rigidi di gestione della documentazione per
Document Management (Content
la qualità con template predefiniti e adattati al
Management, Document Workflow etc.);
processo da controllare, il Wiki favorisce un
Project Management (Activity Management
approccio “collaborativo” in cui è possibile per gli
etc.);
utenti, in modo controllato, modificare le form
Knowledge Sharing (Blog, Forum, Newsletters
proposte per aggiungere informazioni, classificare
etc.).
gli item informativi in modo originale e quindi
Con il diffondersi delle tecnologie legate al raccogliere, da parte di stakeholder, utenti,
Semantic Web [2], gli Enterprise Wiki hanno programmatori etc., con maggiore facilità
acquisito la possibilità di estendere il testo con informazioni non completamente prevedibili a
metadati di markup e consentono all’utente di priori.
effettuare delle “annotazioni semantiche” *3+ utili
Questa libertà di proposta favorisce l’utilizzo della
per il recupero successivo delle informazioni per
documentazione come strumento operativo che
fare incroci, confronti etc.
“vive” nella comunità degli utenti riducendo i rischi
Uno dei “Wiki Engine”con queste caratteristiche è di obsolescenza.
SMW+ (Semantic MediaWiki) con le estensioni Halo
[3], add-in di MediaWiki ([8], [9]), il Wiki engine Un esempio applicativo: la raccolta dei
utilizzato dalla celeberrima Wikipedia [10].
requisiti
SMW+, che implementa delle soluzioni facenti
parte del Web Semantico come RDF [2], è stato Per illustrare le possibilità della soluzione proposta
usato nella realizzazione del prototipo presentato è stato sviluppato un prototipo di applicazione
in questo articolo per creare delle form per Web che traccia il processo di lavorazione dei
l’inserimento di informazioni semistrutturate come requisiti assumendo un ciclo di vita del software
Requisiti, Use Case e Test Case e per definire le adatto a piccole realtà (Very Small Entity). Si è così
corrispondenti relazioni di tracciabilità. ipotizzato un modulo d’inserimento e descrizione
dei requisiti nel Wiki come quello mostrato di
La flessibilità dello strumento ha consentito di seguito.
realizzare agevolmente componenti di
presentazione quali: Ogni requisito possiede un codice univoco, un
titolo, una tipologia, una priorità e una descrizione.
Liste generate automaticamente per Un requisito, una volta inserito, può essere
confrontare l’input e l’output di attività, discusso, modificato, versionato e approvato.
l’elenco degli Use Case con i Test; liste che
risultano sempre attuali a fronte dell’ A valle del consolidamento dei requisiti si
produrranno gli Use Case che, nello scenario degli
3I wiki e il controllo qualità del software
eventi, delineano la funzionalità applicativa. La Il terzo elenco riporta infine la matrice di copertura
Figura 2 mostra la forma per l’inserimento di un dei requisiti da parte dei casi d’uso permettendo di
caso d’uso con tale strumento sperimentato. controllare che nessun requisito rimanga fuori
dalla progettazione e, nello stesso tempo, in quanti
casi d’uso diversi lo stesso requisito è indirizzato
nell’ambito dell’applicazione.
Analogo discorso è stato fatto per i “casi di test”.
Un form specifico permette di descrivere un caso
di test nei termini tradizionali (codice univoco,
titolo, obiettivo, dati in ingresso, azioni da svolgere
e risultati attesi) e di identificare i requisiti che
s’intende verificare.
Analoghe liste di controllo mostrano la matrice di
copertura dei requisiti da parte dei casi di test e, ai
fini della progettazione, la matrice di copertura dei
Figura 2 - Form per l’inserimento dei casi d’uso casi di test rispetto ai casi d’uso.
A fronte della descrizione del caso d’uso, l’utente Vale la pena di osservare come è stata generata la
può selezionare i requisiti direttamente indirizzati matrice di copertura “Requisiti vs Use Case”.
dallo Use Case. Queste informazioni di tracciabilità
La query, scritta nel linguaggio di query sparql [5],
permettono il controllo e il tracciamento dei
che seleziona tutti i requisiti con o senza un caso
requisiti confluiti negli Use Case.
d’uso collegato, viene scritta utilizzando lo stesso
editor del Wiki usato da utenti ed analisti per
scrivere la documentazione e nella stessa pagina,
in modalità di edit, che visualizza il suo risultato,
riportata in Figura 3.
Questa capacità di incorporare istruzioni e testo
facilita enormemente la modificabilità dello
strumento da parte degli utenti stessi dando loro la
possibilità di intervenire ritagliandolo secondo le
esigenze della comunità che lo usa.
Conclusioni e sviluppi futuri
Il prototipo realizzato ha permesso di sperimentare
Figura 3 – matrici di copertura requisiti-casi d’uso diversi aspetti all’interno del ciclo di vita del
software. Un primo risultato ha permesso un
Nella Figura 3 sono infine riportati diversi elenchi
controllo della qualità puntuale durante tutte le
che permettono di costruire matrici di tracciabilità.
fasi del ciclo di vita tramite la costruzione delle
Dapprima è riportato l’elenco dei casi d’uso con
matrici di copertura in tempo reale e mantenute
relativo codice univoco, obiettivo, attori coinvolti
costantemente aggiornate. In ogni fase (meglio
ed evento indirizzato dal caso.
sarebbe dire in ogni momento) si aveva il controllo
Il secondo elenco riporta la matrice di copertura sui requisiti e il loro sviluppo di fase in fase.
dei requisiti indirizzati da parte dei singoli casi Nell’ultima fase di test, infine, la matrice di
d’uso, permettendo di controllare l’ambito (scope) copertura ha permesso di ottimizzare il tempo a
del singolo use case (quali requisiti indirizza). disposizione consentendo di progettare un numero
di casi di test sufficienti a coprire tutti i requisiti e a
evitare duplicazioni e ridondanze.
La mancanza di dati storici (problema endemico di
tutte le organizzazioni software, piccole, medie e
grandi) non ha permesso, purtroppo, di effettuare
confronti con il passato e valutare eventuali
4I wiki e il controllo qualità del software
miglioramenti nelle prestazioni del progetto altre soluzioni proprietarie esistenti sul mercato.
(produttività nelle varie fasi del ciclo di vita). Anche se parziali, i risultati ottenuti fanno ben
Sicuramente si è notato un miglioramento nella sperare e promettiamo di ritornare con un articolo
qualità del software rilasciato con un numero più dettagliato sull’argomento.
medio di errori riscontrati in produzione inferiore a
progetti analoghi realizzati dal gruppo di sviluppo BIBLIOGRAFIA
oggetto della sperimentazione. Il prototipo è stato [1] Wikinomics, Don Tapscott, Anthony D.
infatti messo in esercizio presso il gruppo di lavoro Williams, ETAS, 2007
che l’ha realizzato ed è utilizzato come strumento [2] The Semantic Web, T. Berners-Lee, Scientific
per la produzione della documentazione tecnica di American 2001
progetto. [3] SMW+:
In una seconda fase il prototipo è stato http://semanticweb.org/wiki/SMW%2B
ulteriormente arricchito con una funzionalità [4] ISO/IEC 29110 - Life Cycle Profiles for Very
importante che permette di produrre la Small Entities (VSEs)
documentazione tecnica richiesta dai progetti [5] SPARQL Query Language for RDF, W3C
(documento dei requisiti, specifiche funzionali Recommendation 15 January 2008,
tramite casi d’uso e casi di test) utilizzando http://www.w3.org/TR/2008/REC-rdf-sparql-
direttamente i dati del progetto gestiti dal Wiki e query-20080115/
adoperando dei modelli (template) per produrre [6] Calero, Ruiz et. al., Ontologies for Software
documenti elettronici (.doc). Engineering and Software Technology,
Springer, 2006
Un secondo vantaggio di sicuro appeal è costituito [7] West, Using Wikis for Online Collaboration,
dl fatto che i Wiki sono una tecnologia open source Wiley, 2009
e quindi adoperabili a costo zero. [8] Barrett, MediaWiki, O’Reilly, 2009
Un terzo vantaggio è costituito dall’aderenza [9] Mediawiki, http://www.mediawiki.org
“nativa” di queste applicazioni all’Architettura [10] Wikipedia, http://it.wikipedia.org
Cloud Computing. In particolare la possibilità di
aggiungere/modificare form, scrivere query etc. via
web consente non solo l’accesso alla base
informativa ma anche lo sviluppo “continuo” su
un’applicazione facilmente virtualizzabile.
Un ulteriore vantaggio è costituito dalla possibilità
di integrazione con un’ontologia per linguaggio
controllato, migliorando così enormemente la
comunicazione all’interno del gruppo di sviluppo e,
se collegato, con gli utenti finali e con gli
stakeholder del progetto (Management e
Committenza). Da ciò deriverebbe un
miglioramento significativo anche della qualità
finale del software potendo risolvere, in buona
parte, i problemi (gli errori) dovuti alla cattiva
interpretazione dei requisiti e di ogni altra forma di
comunicazione.
Ultimo vantaggio, ma non di minore importanza, è
costituito dalla possibilità di avere la
documentazione tecnica aggiornata e prodotta in
maniera automatica.
Le dimensioni modeste del prototipo realizzato e
del relativo gruppo di lavoro coinvolto richiedono
ulteriori sperimentazioni per affinare la soluzione e
ricavare maggiori informazioni da confrontare con
5Puoi anche leggere
