Scopo
|
Per selezionare un insieme di casi di utilizzo o di scenari da considerare durante l'iterazione.
Per selezionare un insieme di requisiti non funzionali che deve essere gestito durante
l'iterazione.
|
Linee guida Piano di iterazione
|
L'ambito di un'iterazione è determinato da quattro fattori:
-
i rischi maggiori del progetto
-
la funzionalità richiesta del sistema
-
il tempo assegnato all'iterazione nella pianificazione del progetto
-
la fase ed i relativi obiettivi specifici (See Concetto:
Fase)
Durante la pianificazione iniziale di un'iterazione, viene selezionato sufficiente lavoro per riempire il tempo già
pianificato per l'iterazione - sebbene al responsabile di progetto sia concessa la possibilità di gestire limitazioni
delle risorse e altre considerazioni tattiche durante lo sviluppo del piano di iterazione. Ovviamente, il lavoro
pianificato per la precedente iterazione ma non completato (dal momento che è stato ridotto l'ambito dell'iterazione
precedente per soddisfare la tempificazione del piano) avrà normalmente una priorità elevata.
L'ambito del lavoro viene anche guidato da un sensibile approccio verso il massimo livello di risorse che è possibile
applicare, nella durata dell'iterazione, per raggiungere il completamento. Ad esempio, non è generalmente possibile
raddoppiare il lavoro completato in un'iterazione raddoppiando il personale ad esso assegnato - anche se quelle risorse
erano disponibili. Il numero approssimativo di personale che può essere assegnato in modo efficiente è determinato
dall'architettura e dalle dimensioni complessive del software e dai modelli di valutazione come il COCOMO II
(consultare [BOE00]).
L'esecuzione di un'iterazione è quindi gestita dalla pianificazione
- vale a dire, l'ambito e la qualità (in termini di difetti rilevati non rettificati) sono gestiti attivamente per
soddisfare la data finale.
Esistono tre principali conduttori per la definizione degli obiettivi di un'iterazione nell'elaborazione:
-
Rischio
-
Criticità
-
Copertura
Il conduttore principale per definire gli obiettivi di iterazione sono i rischi. E' necessario mitigare o
ridurre i rischi quanto prima possibile. Si tratta prevalentemente del caso nella fase di elaborazione, dove la maggior
parte dei rischi devono essere mitigati, sebbene possa continuare ad essere l'elemento chiave nella fase di costruzione
dal momento che alcuni rischi restano alti o nuovi rischi vengono rilevati. Poiché l'obiettivo nella fase di
elaborazione è di creare una linea di base dell'architettura, occorre evidenziare alcune altre considerazioni, come la
necessità di essere certi che l'architettura affronti tutti gli aspetti del software da sviluppare (copertura).
Questo aspetto è importante poiché la progettazione sarà utilizzata per ulteriori pianificazioni: organizzazione del
team, preventivo del codice da sviluppare, ecc.
Infine, finché concentrarsi sui rischi è importante, occorre tenere presente quali sono gli obiettivi primari del
sistema; risolvere tutte le problematiche difficili è fondamentale, ma ciò non deve essere effettuato a danno della
funzionalità principale: accertarsi che le funzioni o i servizi critici del sistema siano effettivamente tutelati
(criticità), anche se non si percepisce alcun rischio associato ad essi.
Dall'elenco Rischio, per i rischi maggiormente dannosi, identificare possibili scenari di casi di utilizzo che
costringerebbe il team di sviluppo ad "affrontare" il rischio.
Esempi
-
se esiste un rischio di integrazione come "database D funzionante correttamente con OS Y", accertarsi di
includere uno scenario che interessi una determinata interazione di database seppure molto modesta.
-
se esiste un rischio di prestazione come "tempo per calcolare la traiettoria del aeromobile", accertarsi di
avere uno scenario che includa questo calcolo, almeno per il caso più ovvio e frequente.
Per criticità, accertarsi che le funzioni o i servizi più fondamentali forniti dal sistema siano inclusi.
Selezionare uno scenario non compreso nel caso d'uso che rappresenta la forma più comune e più frequente della funzione
o del servizio offerto dal sistema. Il Documento dell'architettura del software è utilizzato per gestire
questo impegno, fornendo una serie con priorità di casi d'uso o di flussi secondari dei casi d'uso, selezionati dall'Architetto di software per rispecchiare gli scenari o i casi d'uso
significativi strutturalmente.
Esempio
-
per un centralino telefonico, la semplice chiamata stazione a stazione è l'operazione più ovvia per una prima
interazione. Ciò è molto più importante delle complesse modalità di errore nella configurazione operatore del
sistema di gestione degli errori.
Per copertura, verso la fine della fase di elaborazione, includere degli scenari che richiamano delle aree che
richiederanno un processo di sviluppo, sebbene essi non presentino criticità o rischio.
E' conveniente di frequente creare degli scenari end-to-end estesi che riportino più problematiche contemporaneamente.
Il pericolo è di creare degli scenari troppo "pesanti", ad esempio, tentando di descrivere troppi aspetti e varianti
diversi, con notevoli casi di errore (consultare Piano di
iterazione)
Inoltre, nella fase di elaborazione, tenere presente che alcuni rischi potrebbero essere di natura programmatica o
umana: team, istruzione, formazione, selezione degli strumenti, nuove tecniche e così via; solo mediante l'iterazione è
possibile ridurre questi rischi.
Esempi
-
Creare un record di sottoscrizione in una stazione di lavoro client da memorizzare nel database presente nel
server, includendo la finestra di dialogo utente ma non inserendo tutto il campo e supponendo che nessun errore
sia stato rilevato.
Associa una funzione critica ad alcuni rischi di integrazione (database e software di comunicazioni) e
alle problematiche di integrazione (gestione su 2 piattaforme diverse). Inoltre, occorre che i progettisti
siano costretti ad acquisire dimestichezza con il nuovo strumento di progettazione GUI. Infine viene creato un
prototipo che può essere mostrato all'utente per il feedback.
-
Accertarsi che sia possibile creare fino a 20.000 sottoscrittori e che il relativo accesso non sia superiore
a 200 millisecondi.
Segnala alcuni problemi chiave sulle prestazioni (volumi o dati e tempo di risposta), che potrebbero
influire drammaticamente sull'architettura se non risolti.
-
Annullare una modifica dell'indirizzo del sottoscrittore.
Una semplice opzione che imponga ai progettisti di immaginare una progettazione di tutte le funzioni
"annulla operazione". Ciò potrebbe attivare qualche retroazione che gli utenti possono annullare ad un costo
ragionevole.
-
Completare tutti i casi d'uso relativi alla gestione della catena di fornitura.
L'obiettivo della fase di elaborazione è di completare anche l'integrazione dei requisiti, probabilmente
serie per serie.
Quando il progetto si sposta nella fase di costruzione, i rischi restano un elemento chiave, soprattutto quando vengono
individuati nuovi rischi non previsti. Tuttavia la completezza del caso d'uso inizia ad essere un elemento conduttore.
Le iterazioni possono essere pianificate funzione per funzione, tentando di completare in anticipo alcune delle più
critiche, in modo che possono essere completamente verificate durante più di un'iterazione. Verso la fine della
costruzione, l'obiettivo principale sarà la solidità dei casi di utilizzo completi.
Esempio
-
Implementa tutte le varianti di deviazione delle chiamate, comprese quelle errate.
Si tratta di un insieme di funzioni associate. Una di queste funzioni potrebbe essere stata implementata
durante la fase di elaborazione e servirà come prototipo per il resto del processo di sviluppo.
-
Completare tutte le funzioni dell'operatore telefonico ad eccezione del servizio notturno.
Un altro insieme di funzioni.
-
Raggiungere 5.000 transazioni ad ora su una configurazione a 2 computer.
Ciò potrebbe migliorare la prestazione richiesta rispetto al risultato che è stato realmente ottenuto
nella precedente iterazione (solo 2.357/ora)
-
Integrare una nuova versione del GIS (Geographical Information System).
Si tratta di una modifica strutturale modesta, giustificata da qualche problema rilevato precedentemente.
-
Correggere tutti i difetti di livello 1 e 2
Corregge i difetti rilevati durante il test nella precedente iterazione e non immediatamente corretti ma
rinviati.
Il completamento di questa realizzazione del prodotto è l'obiettivo principale. Lo scopo di un'iterazione è posto in
termini di quali errori sono corretti e quali miglioramenti delle prestazioni o dell'utilizzo sono inclusi. Se è stato
necessario abbandonare delle funzioni (o disabilitarle) per poter arrivare in tempo alla fine della costruzione (punto
cardine IOC o "beta"), è possibile ora completarle o attivarle, a patto che non mettano a repentaglio gli obiettivi
raggiunti finora.
Esempi
-
Correggere tutti i problemi di severità 1 rilevati sui siti beta del cliente.
Un obiettivo in termini di qualità potrebbe essere associato alla credibilità sul mercato.
-
Eliminare tutte le interruzioni del sistema di avvio a causa di dati non corrispondenti.
Un altro obiettivo espresso in termini di qualità.
-
Raggiungere 2.000 transazioni al minuto.
Miglioramento delle prestazioni con ottimizzazione del processo: modifica della struttura dati,
memorizzazione nella cache e algoritmo definito maggiormente.
-
Ridurre il numero di diverse caselle di dialogo del 30%.
Migliorare l'utilizzabilità riducendo la distorsione visiva
-
Produrre versioni tedesche e giapponesi.
La versione beta è stata prodotta solo per clienti di lingua inglese per mancanza di tempo e per ridurre
il processo di rilavorazione.
|