|
|
|
|
|||||||
|
Ercole Colonese |
|||||||||
|
L’ESPERIENZA AL VOSTRO SERVIZIO! |
|||||||||
|
Consulenza informatica ed organizzativa |
|||||||||
|
|
|||||||||
|
|
(Who am I?) |
||||||||
|
|
Sviluppo software, oggi, in Italia ... |
||||||||
|
Stonehenge
In questa pagina:
"Best practice" del software (selezionate quella di vostro interesse): 1. Analisi accurata dei requisiti 2. Qualità della progettazione 5. Gestione attenta dei rischi 7. Revisione tecnica dei prodotti intermedi realizzati 8. Adeguatezza dei test alla criticità del business 9. Utilizzo di processi, metodi, tecniche e strumenti adeguati |
"Best practice" del software Le 10 "best practice" proposte sono descritte in termini di contenuti, modalità di svolgimento corretto, risultati positivi conseguiti dall'adozione della pratica e potenziali problemi generati dalla mancata o errata adozione della pratica. Forniscono la massima efficacia quando cliente e fornitore, pur con ruoli diversi e contrapposti, collaborano al successo del progetto. L'analisi dei requisiti è una delle prime ed anche una delle principali pratiche. Dalla sua efficacia dipenderà il resto del progetto. L'ingegneria del software indica questa attività importante come "ingegneria dei requisiti". 1. Analisi accurata dei requisiti Contenuti della pratica E' noto a chiunque si occupi di sviluppo software l'importanza che riveste l'analisi dei requisiti per il buon esito di un progetto. E' altrettanto noto che i requisiti iniziali possono cambiare durante il progetto e che tali cambiamenti debbano essere gestiti opportunamente. E' meno noto, invece, che requisiti, anche ben definiti, assumono un significato diverso per noi che sviluppiamo il software e per gli utenti che tale software dovranno poi utilizzarlo. Il modello Servqual per la qualità dei servizi indica lo scostamento ("gap") tra il servizio atteso e quello percepito dal cliente finale come uno dei fattori di maggiore insoddisfazione. Risulta quindi di assoluta importanza "condividere" il significato dei requisiti con gli utenti finali e garantire una univocità di interpretazione. L'interpretazione ed il grado di importanza che gli utenti danno ai requisiti dipende dal contesto nel quale essi operano: responsabilità loro assegnate, contenuti dei task da completare, modalità di svolgimento dei propri compiti, preferenze ed abitudini consolidate nel tempo, ambiente culturale ed organizzativo nel quale operano. I requisiti assumono il loro corretto significato e la giusta importanza solo quando riferiti allo scenario operativo, organizzativo e culturale in cui nascono e sono percepiti. Analogamente, la soluzione proposta a fronte dei requisiti definiti è valutata correttamente solo nel contesto in cui essa sarà utilizzata dagli utenti. La pratica proposta per l'analisi dei requisiti prevede quanto segue:
Ciascuna attività risulta particolarmente efficace se svolta secondo le modalità descritte di seguito. Modalità di svolgimento della pratica a) Raccolta, analisi e documentazione dei requisiti. La "raccolta dei requisiti" è svolta partendo da diverse fonti e con modalità diverse: analisi della documentazione fornita dal cliente o già in nostro possesso; interviste a persone del cliente direttamente coinvolte nel progetto o comunque direttamente interessate al successo del progetto; discussioni con il cliente in circostanze diverse ma attinenti al progetto ed ai suoi contenuti; ecc. E' bene prendere nota di tutte queste fonti e formalizzarne i contenuti. L' "analisi dei requisiti" consiste nell'interpretare i requisiti raccolti, dare a ciascuno di essi un significato univoco, chiaro, completo, consistente, coerente con gli altri requisiti e testabile, definire la tipologia del requisito ("funzionale" o "non-funzionale"), definire l'importanza che il requisito riveste per il business (alta, media o bassa) ed assegnare una priorità (alta, media, bassa) che permetta di stabilire quando implementare il requisito nell'ambito del progetto. Un software che realizzi una funzionalità lo fa con determinate caratteristiche. Per esempio, una funzione è utilizzabile dall'utente cui è rivolta in maniera più o meno semplice, con prestazioni più o meno alte, garantendo o meno la sicurezza, ecc. Mentre un requisito "funzionale" descrive la funzionalità richiesta, i requisiti "non funzionali" identificano le caratteristiche con cui la funzionalità dovrà essere resa disponibile. I requisiti non funzionali sono sempre presenti anche se spesso non sono esplicitamente espressi in quanto ritenuti ovvi. Si dicono perciò impliciti ma sono ugualmente richiesti, attesi e quindi valutati in fase di accettazione della soluzione finale. Le norme ISO 9126 definiscono un modello della qualità del software secondo due diversi punti di vista: il primo definisce le caratteristiche e gli attributi del software secondo un punto di vista "interno ed esterno", il secondo definisce le caratteristiche dal punto di vista del suo utilizzo. Le caratteristiche interne ed esterne del software sono: Funzionalità, Affidabilità, Usabilità, Efficienza, Manutenibilità, Portabilità. Ciascuna di esse ha attributi specifici. Le caratteristiche del software secondo il suo utilizzo sono invece: efficacia, produttività, sicurezza e soddisfazione. Nel sito è descritto il modello e le caratteristiche del software. Nel documentare un requisito occorre essere estremamente precisi per assicurare che esso sia interpretato da tutti nello stesso modo. Un requisito deve essere quindi "chiaro, univoco, completo, consistente, coerente con tutti gli altri requisiti, e testabile". Ciascun aggettivo menzionato ha una sua importanza specifica ai fini di una corretta descrizione dei requisiti. Per "documentare i requisiti" è bene utilizzare uno schema consolidato che permetta di gestire nel corso del progetto i requisiti, la loro implementazione ed i possibili cambiamenti. Tale documento rappresenta il "Riferimento" più importante in tutto il progetto e ad esso faremo anche noi riferimento nelle altre pratiche proposte. Il documento dei requisiti può essere anche un semplice foglio di calcolo con le seguenti colonne: Identificativo univoco del requisito, Titolo del requisito, Tipologia del requisito, Importanza del requisito, Priorità del requisito, Descrizione dettagliata del requisito, Stato del requisito, Data in cui lo stato è definito o cambiato, Condivisione del requisito, Data della condivisione, Fonte del requisito, Inclusione del requisito nella progettazione, Inclusione del requisito nei casi di test, Nota informativa con dettagli che possano aiutare a gestire il requisito. Qui è fornito un esempio di "Tabella dei requisiti". Un modo concreto ed efficace di rappresentare l'interpretazione che diamo dei requisiti è quello di tradurli in scenari operativi, detti "casi d'uso" (in inglese "use case"). Essi descrivono le modalità con cui gli utenti interagiscono con il sistema per svolgere determinati compiti. La modellazione dei requisiti con la tecnica degli "use case" permette quindi di concentrare l'attenzione sugli utenti e le modalità operative. Una funzione è perciò descritta non in maniera astratta ma come essa sarà utilizzata da un particolare utente per svolgere un determinato compito. b) Condivisione dei requisiti con il cliente. La "condivisione dei requisiti" è fondamentale per garantire l'univocità della loro interpretazione. Consiste nel condividere con il cliente i requisiti ed i casi d'uso. La descrizione dei requisiti, le tipologie, l'importanza e le priorità permettono di condividere l'interpretazione dei bisogni del cliente. La descrizione dei casi d'uso permette di condividere gli scenari operativi nei quali il software sarà utilizzato dagli utenti finali. Solo la condivisione può garantire che la nostra interpretazione delle esigenze del cliente coincida con la sua e che, in fase di sviluppo, andremo a realizzare una soluzione come quella descritta dai casi d'uso. Sarà perciò chiaro e pacifico ad entrambi che si andrà a sviluppare una soluzione che indirizzi i "requisiti condivisi" e non la "nostra interpretazione di essi". Le caratteristiche del software (requisiti non funzionali) non sono generalizzabili all'intera applicazione ma legate a specifiche funzionalità ed alle modalità con cui gli utenti finali le utilizzeranno. La condivisione dei requisiti va fatta, quindi, con diversi utenti finali (o categorie di utenti finali) a seconda delle funzionalità in discussione. L'assegnazione di una priorità (o importanza) ad ogni requisito permette di organizzare il progetto in fasi con rilasci successivi e contenenti i requisiti secondo le priorità condivise con il cliente. Ogni modifica ai requisiti iniziali seguirà lo stesso processo descritto: la condivisione con il cliente garantisce la consistenza e la congruenza con quanto già condiviso e indirizzato nel progetto. La tabella dei requisiti (indicata come "Riferimento") è aggiornata con quanto condiviso ed è mantenuta aggiornata durante l'intera durata del progetto come vedremo nel proseguo. c) Verifica che i requisiti siano indirizzati nella progettazione. Il documento dei requisiti è la base per la progettazione. Il responsabile del design assicura che essi siano tutti correttamente indirizzati nella progettazione. La verifica tiene conto sia dei requisiti funzionali che di quelli qualitativi. La progettazione deve quindi garantire che le funzionalità sviluppate possano essere utilizzate dagli utenti finali nei loro contesti di lavoro: responsabilità loro assegnate, diversi compiti da svolgere, modalità di utilizzo, preferenze e criteri di valutazione. Una funzione semplice come, ad esempio, l'inserimento di dati avrà caratteristiche diverse in termini di usabilità, prestazioni e sicurezza a seconda dello scenario nel quale l'utente finale la utilizzerà. Una funzione realizzata tramite una transazione batch richiederà tempi di lavorazione differenti rispetto alla stessa funzione svolta in modalità on-line da un operatore che abbia davanti al suo sportello una coda di utenti in attesa. Una transazione svolta da un utente remoto sul Web ha requisiti di sicurezza diversi dalla stessa transazione eseguita da un utente autorizzato nel sistema informativo aziendale interno, ecc. La verifica della bontà della progettazione tiene conto, dunque, del fatto che essa indirizzi correttamente e completamente i requisiti condivisi con il cliente, sia quelli funzionali che quelli qualitativi, con le priorità e le criticità definite. La verifica della progettazione include l'aggiornamento della tabella dei requisiti (indicata come "Riferimento") riportando per ogni requisito l'indicazione se esso sia stato correttamente e completamente indirizzato dalla progettazione in esame. d) Stima e pianificazione del progetto partendo dai requisiti. La stima del progetto deve partire sempre dall'elenco dei requisiti condivisi. La stima tiene conto sia delle caratteristiche funzionali che di quelle qualitative. Lo sviluppo di una funzionalità può richiedere infatti tempi e costi diversi a seconda delle sue caratteristiche qualitative. Una soluzione senza requisiti di sicurezza, ad esempio, costerà meno di una in cui tale caratteristica sia critica per il business. Analogamente una funzionalità con alte prestazioni (es.: tempi di risposta inferiori ad un valore di soglia) avrà costi superiori ad un'analoga funzioni senza tali caratteristiche prestazionali, ecc. Occorre dunque assicurare che le stime siano fatte basandosi sulla tabella dei requisiti (presa come "Riferimento") e che tutti i requisiti siano stati presi in considerazione. Si comprende bene come ogni modifica ai requisiti iniziali possa influire sulle stime fatte e richiedere quindi che queste siano aggiornate ed approvate prima che la modifica sia inclusa nel progetto. e) Progettazione dei test partendo dai requisiti. Il documento dei requisiti ("Riferimento") è la base di partenza per la progettazione dei test. Occorre garantire che ogni requisito, funzionale e qualitativo, sia indirizzato da almeno un caso di test. Così si garantisce che le funzionalità e le caratteristiche del software siano verificate nella loro completezza e correttezza. Per assicurare la massima copertura dei requisiti da parte dei test è bene creare una matrice (detta "matrice di test") la quale riporta l'elenco dei requisiti e l'elenco dei casi di test. La casella di incrocio tra requisito e caso di test indica se la copertura è assicurata o meno. Una tale matrice permette di verificare il grado di copertura dei requisiti e consente allo stesso tempo di ottimizzare i test. Un requisito che sia coperto da più casi di test, per esempio, suggerisce di eliminare i casi di test duplicati che non aggiungono valore al test del requisito. Al contrario, la matrice può rilevare che alcuni requisiti non siano opportunamente indirizzati da casi di test. Qui è fornito un esempio di "Matrice di test". f) Gestione delle modifiche dei requisiti durante l'intero durata del progetto. L'importanza della gestione delle modifiche ai requisiti iniziali è ora chiara più che mai a tutti noi. Ogni modifica ai requisiti deve seguire tutte le fasi elencate e descritte in precedenza in quanto essa può avere influenza su vari aspetti del progetto: interpretazione del suo contenuto, progettazione della soluzione, stima dei tempi e dei costi, piano dei test. La modifica dei requisiti iniziali richiede l'approvazione dei responsabili del progetto, sia lato cliente che lato fornitore, prima della sua inclusione nel progetto stesso. Risultati positivi conseguiti dall'adozione della pratica Il risultato dell'adozione di tale pratica è importante ai fini del successo del progetto e consiste in:
I benefici elencati sono stati personalmente verificati in molti progetti, sia semplici che complessi, in cui la "best practice" è stata adoperata. L'adozione della pratica non richiede alcun costo aggiuntivo al progetto in quanto l'analisi dei requisiti sarà svolta "in maniera diversa" piuttosto che con attività aggiuntive. La formazione iniziale del personale è da considerarsi un investimento dell'azienda e non un costo addebitabile al singolo progetto. Potenziali problemi generati dalla mancata o errata adozione della pratica I problemi derivanti da una errata analisi dei requisiti sono rilevanti, conosciuti da tutti noi e messi in luce dall'indagine in corso. I più importanti sono:
L'analisi dei dati ricavati dall'indagine in corso e l'esperienza maturata in molti anni di lavoro e progetti diversi identifica nella mancata o scarsa adozione di tale "best practice" l'origine principale dei problemi evidenziati sopra. |
Nel sito si possono trovare le seguenti aree di interesse:
Partecipate all'indagine sul livello di adozione delle best practice nelle organizzazioni software italiane: Scaricate il Questionario con le 10 domande e speditelo compilato all'autore all'indirizzo: ercole@colonese.it
La descrizione delle pratiche proposte e di come adoperarle correttamente nei progetti è fornita nella pagina indicata qui di seguito dove è possibile selezionare la pratica di nostro interesse: Best practice del software proposte
|
|||||||
|
|
Copyright © 2005-2008 - Ultimo aggiornamento: 23 agosto 2008 |
||||||||
