Attività del ciclo di vita:
-
Introduzione
-
Attività della fase di inizio
-
Attività della fase di elaborazione
-
Attività della fase di costruzione
-
Attività della fase di transizione
Lo sviluppo basato su componenti è una variazione dello sviluppo generale di un'applicazione in cui:
-
L'applicazione viene assemblata da dei discreti componenti eseguibili che vengono sviluppati e
distribuiti in maniera relativamente indipendente gli uni dagli altri, potenzialmente da team diversi.
-
L'applicazione può essere aggiornata tramite incrementi più piccoli, aggiornando solo alcuni dei
componenti che compongono l'applicazione.
-
I componenti possono essere condivisi fra le applicazioni, creando non solo delle opportunità di
riutilizzo ma anche delle dipendenze all'interno del progetto.
-
Le applicazioni basate su componenti tendono ad essere distribuite, anche se questo non è strettamente
correlato all'essere basate su componenti.
In tutta la pagina il termine "componente" viene utilizzato per indicare i componenti sviluppati e distribuibili in
modo indipendente. Altrove in RUP, tuttavia, verrà utilizzato il termine "componente" in senso più generale, descritto
in Concetto: Componente, e quando necessario, verrà qualificato.
Di seguito viene descritto l'adattamento di RUP (Rational Unified Process) alle sfide dello sviluppo basato sui
componenti.
Alla fase di inizio viene applicato il flusso di lavoro di base, con le seguenti
estensioni o variazioni:
Gestione del progetto
-
Attività: Pianificazione del progetto
-
Nel Compito: Pianificazione delle fasi e delle iterazioni, il
piano per la fase di costruzione può potenzialmente mostrare il progetto suddiviso in due tracce differenti ma
parallele: una che sviluppa i componenti specifici per l'applicazione e per il dominio (organizzati nei livelli
superiori dell'architettura - consultare Concetto:
Livelli) e l'altra dei componenti non specifici per l'applicazione o per il dominio, organizzati nei
livelli inferiori. In alcuni casi, i componenti riutilizzabili vengono sviluppati da team di sviluppo gestiti
in modo indipendente. La decisione di introdurre delle tracce parallele è principalmente una problema di
personale e di risorse, sorta dal desiderio di gestire dei componenti riutilizzabili come beni indipendenti
delle applicazioni in cui in cui vengono sviluppati.
Requisiti
Test
Ambiente
-
Attività: Preparazione dell'ambiente per il progetto
-
Quando si raccolgono e si preparano le linee guide del progetto, consultare il Compito: Preparazione delle linee guida per il progetto per i
dettagli tenere in considerazione lo specifico framework componenti ed i vincoli da esso imposti. Le linee
guida devono includere come progettare e creare il codice tramite il framework. Devono inoltre fornire una
guida per il test relativo alla verifica della conformità sia con lo stesso framework componenti che con
le interfacce definite fra i componenti.
Per la fase di elaborazione viene applicato il flusso di lavoro di base, con le seguenti
estensioni o variazioni:
Requisiti
-
Attività: Perfezionamento della definizione del sistema
-
Il Compito: Dettagli dei requisiti software concentra
ulteriormente l'attenzione sui requisiti tecnici e non funzionali e sui vincoli imposti ai componenti creati o
comprati. I requisiti specifici non funzionali da considerare sono la dimensione, le prestazioni, la quantità
di RAM del disco o della memoria, le problematiche runtime inerenti alle licenze e vincoli simili, che
influenzano la selezione o la costruzione del componente.
Analisi e progettazione
-
Attività: Progettazione di componenti
-
Il Compito: Progettazione dei sottosistemi perfeziona
ulteriormente la progettazione dei componenti, identificando le classi all'interno del componente che
forniscono l'effettiva funzionalità del componente. Allo stadio iniziale della fase di elaborazione
probabilmente esiste un'unica classe, una specie di 'proxy di sottosistema/componente' che agisce da stub per
simulare il funzionamento del componente per la creazione di un prototipo di architettura. In seguito la
funzionalità di quella classe viene distribuita ad una collaborazione di classi contenute nel sottosistema.
Queste classi contenute sono definite in Compito:
Progettazione della classe.
-
Attività: Progettazione del database
-
Il punto focale nell'elaborazione è assicurare che la strategia di persistenza sia scalabile e che il
meccanismo di persistenza e la progettazione del database supportino i requisiti di sistema per la
produttività. Le classi persistenti vengono identificate ed associate al meccanismo di persistenza. I casi
d'uso con molti dati vengono analizzati per verificare che i meccanismi siano scalabili. Oltre alle attività di
verifica, il meccanismo di persistenza e la progettazione del database vengono valutati e convalidati.
Implementazione
Test
-
Attività: Definizione della missione di valutazione, Verifica dell'approccio di test, Test e valutazione, Ottenimento della missione accettabile, Miglioramento delle risorse di test
Le attività di test nella fase di elaborazione si incentrano sulla convalida dell'architettura. Per i sistemi
basati su componenti questo si traduce in:
-
utilizzo delle interfacce fra i componenti, per verificare che i confini dei componenti siano appropriati
-
una maggiore attenzione alla verifica delle prestazioni, specialmente test di scalabilità delle
prestazioni, per verificare che i volumi di transazione anticipati possano essere sostenuti
Deve essere valutata anche qualsiasi eventuale assunzione inerente del framework componenti. In genere sono
incluse la scalabilità e la produttività dei meccanismi di persistenza e di gestione della transazione, nei
quali delle assunzioni nascoste effettuate dal progettista del meccanismo spesso indeboliscono di fatto
l'architettura dell'applicazione, se non viene compresa l'assunzione.
Gestione del progetto
-
Attività: Pianificazione dell'iterazione successiva
Utilizzando i sottosistemi di implementazione come 'unità logiche di responsabilità', il lavoro di costruzione
può essere suddiviso in due o più "tracce" parallele: una che si occupa della funzionalità specifica per
applicazione e le altre (una o più) che si occupano dei componenti generici riutilizzabili. Questo naturalmente
dipende da una sufficiente disponibilità di risorse da assegnare ai paralleli impegni lavorativi relativi allo
sviluppo. La capacità di suddividere i team di sviluppo e di lavorare in parallelo dipende interamente dalla
stabilità dell'architettura e, più nello specifico, dalla qualità e dalla stabilità delle interfacce fra i
componenti. Un valido impegno durante la fase di elaborazione consentirà questa suddivisione.
Alla fase di costruzione viene applicato il flusso di lavoro di base, con le seguenti
estensioni o variazioni:
Gestione del progetto
-
Attività: Pianificazione dell'iterazione successiva
La pianificazione della prima iterazione della costruzione è stata trattata in precedenza, poiché ricorre al
termine della fase di elaborazione. La pianificazione delle successive iterazioni e la possibilità di
suddividere il team di sviluppo e lavorare in parallelo continua a dipendere dalla stabilità dell'architettura
e dalla qualità e stabilità delle interfacce fra i componenti.
Analisi e progettazione
-
Attività: Perfezionamento dell'architettura e Attività: Progettazione dei componenti
Il punto focale della costruzione è l'analisi della parte restante dei casi d'uso e l'identificazione dei
componenti e delle collaborazioni di componenti appropriati che realizzano i casi d'uso. L'architettura
esistente viene espansa e completata, ed i 'comportamenti interni' del componente vengono completamente
progettati ed implementati.
-
Attività: Progettazione del database
Il punto focale della costruzione è completare la progettazione del database, verificando che tutte le classi
persistenti siano supportate sia dal database che dal meccanismo di persistenza. Questo lavoro viene eseguito
in parallelo e in modo iterativo con il lavoro svolto in Attività: Perfezionamento dell'architettura e Attività: Progettazione dei componenti. L'organizzazione
ideale è di disporre di team integrati di componenti, con il coordinamento fra i team sulle problematiche
relative alla persistenza, per garantire una buona progettazione del database.
Implementazione
Test
La verifica delle prestazioni resta importante ma è presente una maggiore attenzione per i test funzionali. E'
necessario occuparsi anche della completezza della funzionalità, della verifica di regresso della funzionalità
esistente e della conformità con le aspettative di prestazione.
-
Il rilascio del prodotto in ambiente web tende ad essere incrementale e continuo, meno incentrato sulla
tradizionale distribuzione dei supporti. La pianificazione dei rilasci deve essere effettuata di conseguenza.
-
Il supporto di produzione è sempre più il punto focale di questa fase.
-
Vengono eseguite le attività di conversione dati.
|