Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente.
In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.
Per maggior chiarezza le attività che si prevede di svolgere in ciascuna fase sono esplicitate nelle sezioni seguenti.
Fase R: Requisiti
L’obiettivo di questa fase consiste nella definizione formale dei requisiti di ciascun sottosistema. Per ottenere tale definizione formale sarà realizzato un ciclo iterativo delle seguenti attività:
1/5
Il ciclo di vita del software applicativo
• Interviste ed incontri con il committente per l’individuazione dei desiderata;
• Analisi Funzionale per l’organizzazione dei desiderata in funzionalità elementari e moduli funzionali.
• Rappresentazione formale delle funzionalità con diagrammi UML (state diagram e use case);
• Redazione dei Report di Analisi Funzionale nei quali i desiderata vengono associati alle singole funzionalità individuate.
Si parla di ciclo iterativo delle attività su elencate in quanto, come si evince dallo schema in Figura, il ciclo di vita incrementale consente di limitare le attività di Fase R ad un sottoinsieme dei desiderata per poi allargare tale sottoinsieme in momenti successivi.
Fase P: Progettazione
L’obiettivo di questa fase consiste nella definizione formale delle caratteristiche tecniche di dettaglio relative a ciascuna delle componenti che costituiscono ciascuno dei sottosistemi individuati in fase R.
Naturalmente il paradigma adottato per la definizione delle componenti software sarà il client/server ad n livelli dunque gli le attività previste in questa fase saranno della tipologia seguente:
• definizione delle informazioni che risulta necessario elaborare per l’implementazione di ciascuna funzionalità individuata in fase R;
• definizione degli schemi di base dati destinati a contenere tali informazioni;
2/5
Il ciclo di vita del software applicativo
• Analisi Tecnica per la progettazione fisica di tali basi dati;
• definizione delle componenti di middleware (o componenti di business logic) che implementano le logiche operative definite in fase R per ciascuna funzionalità;
• Analisi Tecnica per la progettazione fisica di tali componenti;
• Rappresentazione formale delle componenti di middleware con diagrammi UML (class diagram) e delle basi dati (E-R diagram);
• Analisi Tecnica per la progettazione delle interfacce utente dalle quali sia possibile accedere alle funzionalità associate a ciascuna componente di middleware;
• Rappresentazione formale delle interfacce utente e delle modalità di accesso alle funzionalità mediante diagrammi UML (user experience diagram);
• Redazione dei Report di Analisi Tecnica nei quali vengono raccolte le descrizioni di dettaglio di tutte le componenti tecniche individuate.
Anche in questo caso il modello incrementale prevede cicli iterativi delle attività sopra descritte.
Fase C/T: Codifica e testing
Prevede l’implementazione delle componenti tecniche individuate mediante le attività seguenti:
3/5
Il ciclo di vita del software applicativo
• codifica propriamente detta (tipicamente in linguaggio SQL per le basi dati, in linguaggio JAVA per le componenti di middleware e mediante script JSP per le pagine che realizzano le interfacce utente);
• unit test – cioè test estensivo di ciascun metodo di ciascuna componente tecnica, specialmente per le componenti di middleware;
• system test – cioè test complessivo di ciascuna funzionalità di ciascun modulo funzionale (o sottosistema).
Come conseguenza delle interazioni previste in Fase R ed in Fase P anche in fase C/T sono previsti cicli iterativi delle attività.
Fase I/SA: Installazione e supporto all’accettazione
Obiettivo primario di questa fase consiste nella distribuzione di tutte le componenti di un build su un ambiente di verifica realizzato presso il committente. Ciò perché si prevede di eseguire le attività di fase C/T presso i laboratori di sviluppo del RTI.
Una volta che un build sia stato distribuito presso il committente, parallelamente all’esecuzione di attività di fase: R, P, C/T su un build successivo da parte del RTI , il committente può procedere alla validazione delle funzionalità già implementate dando evidenza di eventuali malfunzionamenti o richieste di modifiche sul sistema di Bug Tracking (BugZilla nel caso specifico).
Le attività previste in questa fase sono le seguenti:
• Installazione – cioè distribuzione delle componenti incluse nel build sull’ambiente di prova a disposizione del committente;
4/5
Il ciclo di vita del software applicativo
• Supporto all’accettazione – assistenza al committente durante le fasi di test per il discernimento dei livelli di criticità da assegnare alle eventuali modifiche richieste sul build e per l’accettazione delle funzionalità (e quindi delle componenti) considerate consolidate e concluse.
Anche in questo caso il modello incrementale prevede cicli iterativi delle attività sopra descritte.
Versioning e non regressione
Ad ogni ciclo di build viene associato un numero di versione dell’intero sistema il quale, all’interno dell’ambiente di controllo delle versioni (CVS nel caso specifico) identifica univocamente le versioni specifiche ci tutte le componenti software e di tutti i documenti di Analisi Funzionale e Tecnica aggiornati al momento in cui viene eseguito il build.
Con l’ausilio di uno strumento automatico per l’esecuzione dei test su applicazioni web multilivello (Test Complete nel caso specifico) si avrà la possibilità di effettuare verifiche di non regressione, cioè verifiche che consentono di identificare eventuali malfunzionamenti ingenerati in funzionalità già testate e risultate corrette da modifiche al codice intervenute tra uno specifico build (n) ed il build successivo (n+1).
