|
BENEVENTO & PROVINCIA
QUALCHE IDEA PER LO SVILUPPO
L'INGEGNERIA DEI REQUISITI
FAVORIRE LA TRACCIABILITÀ
L'INGEGNERIA DEI REQUISITI
FAVORIRE LA TRACCIABILITÀ
Comprendere le esigenze dell'utente per gestire il rischio di un progetto
 Gerardo Canfora e Corrado Aaron Visaggio
Centro Eccellenze Tecnologie del Software (RCOST) - Università del Sannio
canfora@unisannio.it
visaggio@unisannio.it
Fino a qualche anno fa, software era sinonimo di codice e quindi produrre software significava scrivere un programma che funzionasse senza troppe anomalie e sufficientemente robusto da ridurre al minimo gli interventi di manutenzione. Questa forte attenzione al codice, perpetrata fino a oggi, ha formato classi di sviluppatori per i quali ogni attività che non sia fortemente correlata alla scrittura di codice è avvertita come inutile e dispersiva. Ma anche la ricerca, per molto tempo, ha posto in rilievo gli aspetti che più o meno direttamente riguardano il codice, raffreddando l'interesse per gli aspetti più lontani da esso, come per esempio la stima dei rischi. Infatti la verifica del codice si avvia a essere una disciplina matura, articolata, che può contare su un ricco bagaglio di sperimentazioni ed esperienze industriali. La stessa cosa, invece, non si può dire per le fasi iniziali del processo di produzione del software, quelle maggiormente legate alla comprensione delle esigente dell'utente. Sebbene ci sia un apprezzabile sforzo nel dare sistematicità anche a questa fase importantissima del ciclo di vita del software, il corpo di conoscenza non può certo dirsi maturo. L'attenzione dei ricercatori e dell'industria si sta spostando sempre più velocemente verso le attività iniziali del processo di produzione del software. Il motivo di tale cambiamento di focus è che si è diffusamente consolidato il principio secondo il quale il costo di rimozione di un difetto è tanto più alto, quanto più avanzata è la fase in cui questo viene identificato. E la scrittura del codice spesso è in una fase avanzata; si consideri che, indicativamente, un processo software tipico è composto dai seguenti stadi: analisi dei requisiti, progettazione, codifica, collaudo e rilascio. I requisiti stanno acquisendo un'importanza crescente nell'industria, tanto che è nata una disciplina che ne studia i diversi aspetti, appunto l'"Ingegneria dei Requisiti". É abbastanza intuitivo comprendere che se non si conosce in maniera precisa "cosa" bisogna realizzare, è altamente "rischioso" iniziare il processo di realizzazione. Tra le diverse problematiche che l'ingegneria dei requisiti intende risolvere, molta rilevanza ha il problema della tracciabilità, soprattutto per le sue ripercussioni sulla gestione del progetto e la riduzione del rischio. Questa ha l'obiettivo di identificare le relazioni 'tra' i requisiti. I requisiti di un prodotto software sono correlati da una fitta rete di dipendenze le quali hanno influenze su tutto il processo di sviluppo fino all'accettazione del prodotto finale. Molti requisiti presentano conflittualità, per così dire, indirette, ovvero che non possono essere individuate immediatamente, ma solo dopo l'applicazione di tecniche appropriate. Consideriamo di voler produrre un sistema per la riproduzione di filmati in remoto. Si consideri il requisito "riproduci il video automaticamente dopo la selezione" (R1) e il requisito "la riproduzione di un video deve avere inizio dopo tre secondi al massimo" (R6). Il requisito R1 richiede un aumento di funzionalità del sistema, cosa che ne diminuisce l'efficienza; ma questo è in conflitto con il requisito R6 che esige, per l'appunto, un aumento di efficienza. Molto spesso questi tipi di conflitti vengono scoperti al momento della codifica; rimuoverli, invece, nella fase di definizione dei requisiti è chiaramente più economico: bisogna, però, realizzare le analisi appropriate. Un altro problema, legato alla tracciabilità, riguarda la "vita" di un requisito. Alcuni requisiti formalizzati al principio del processo di produzione del software, possono "scomparire" durante il processo stesso, cioè possono non avere corrispondenti parti di programma che lo implementano. Questo può accadere per molti motivi. Uno dei più diffusi è che lo sviluppatore, ignorando durante la scrittura del codice, il requisito in questione, realizza lo stesso obiettivo, ma in modo diverso. Per cui nessuno si accorge che il requisito è "scomparso" dal processo, tipicamente fino a quando il cliente fa notare al produttore che il software non è esattamente come lui voleva. Tipicamente questo problema riguarda l'interfaccia utente. Per esempio, consideriamo un programma gestionale che calcoli "c" come la somma delle voci di bilancio "a + b" e la somma "g" come la somma delle voci di bilancio "d+e+f". L'utente vorrebbe visualizzare in realtà "c+g" e non c e g separatamente. La tracciabilità garantisce, tramite strumenti appropriati, che una volta definito un requisito, questo venga collegato alle parti di codice (ma anche a quelle di progetto e ai casi di test) che lo riguardano, così da non perderlo durante lo sviluppo. Una terza utilità della tracciabilità consiste nel fornire una sorta di "barra di avanzamento del progetto". Il problema in questo caso ha due aspetti. Il primo è che utenti e manager considerano il completamento del progetto dal punto di vista dei requisiti "percepiti" all'esterno. Un software è molto altro oltre quello che si vede all'esterno. E questo altro è ciò che invece percepisce lo sviluppatore. Di conseguenza il manager valuta l'avanzamento del progetto generalmente sulla base dei requisiti che percepisce, così come l'utente. I requisiti potrebbero fungere da barra di avanzamento, soprattutto se ben correlati alle parti di software che li implementano. Tramite uno strumento di questo tipo, i manager potrebbero "percepire" l'avanzamento del progetto riferendosi alla percentuale di completamento di tutti i requisiti, anche quelli che loro non vedono. Un'altra funzione della tracciabilità è collegare i requisiti alla conoscenza che è funzionale alla comprensione del requisito ma che non vi può rientrare in modo esplicito. Un tipico esempio sono le regole proprie del dominio applicativo del software. Ritorniamo al nostro programma gestionale. Pochi sviluppatori conosceranno con precisione le formule matematiche e le normative che stanno dietro i calcoli per compilare, per esempio, la busta paga dei dipendenti dell'azienda, anche se un requisito del sistema che devono sviluppare è la produzione della busta paga, completa di voci e percentuali. In tal caso collegare al requisito la documentazione che consente tali collegamenti, eviterebbe molte rilavorazioni ed errori. L'ingegneria dei requisiti non si ferma però a queste problematiche. Non ci sono ancora sul mercato strumenti in grado di realizzare pienamente la tracciabilità dei requisiti e molti problemi di natura metodologica sono aperti. É per questo motivo che, all’RCOST, stiamo studiando queste problematiche e realizzando un prototipo sperimentale di uno strumento che supporti la tracciabilità.
|
