Operazione: Sviluppo del piano di iterazione
Questa attività descrive in che modo comporre un piano di iterazione con definizione dell'ambito, del criterio di valutazione, delle attività e con assegnazione delle responsabilità dell'iterazione.
Scopo

Per sviluppare un piano di iterazione che comprende quanto segue:

  • una struttura di suddivisione dettagliata del lavoro dell'attività e delle assegnazioni di responsabilità
  • punti cardine intra-iterazione e componenti distribuibili
  • criteri di valutazione per l'iterazione
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

L'iterazione stessa è una serie di attività tempificate concentrate strettamente alla produzione di un eseguibile. Per tutte tranne che per l'ultima iterazione di transizione si tratta di un prodotto intermedio, realizzato per rafforzare l'attenzione sulla riduzione dei rischi e sulla guida del progetto verso una consegna riuscita. La concentrazione dell'attenzione su un componente distribuibile ed eseguibile provoca una quasi continua integrazione e consente al progetto di segnalare i rischi tecnici in anticipo, diminuendo i rischi annessi.

L'iterazione implica una certa quantità di rilavorazione (di prodotti di lavoro esistenti) e una modifica di accompagnamento nell'attitudine verso la rilavorazione. In breve, una determinata quantità di rilavorazione è necessaria per consegnare un prodotto di qualità: con la generazione di prodotti intermedi e la valutazione dell'adattabilità dell'architettura del prodotto precocemente e frequentemente, si eleva la qualità del prodotto finale mentre le modifiche da apportare sono meno costose e più facili da accettare.

Passi
Determinazione dell'ambito d'iterazione
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.

Nella fase di Elaborazione :

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Nella fase di Costruzione :

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

  1. 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.
  2. Completare tutte le funzioni dell'operatore telefonico ad eccezione del servizio notturno.
    Un altro insieme di funzioni.
  3. 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)
  4. Integrare una nuova versione del GIS (Geographical Information System).
    Si tratta di una modifica strutturale modesta, giustificata da qualche problema rilevato precedentemente.
  5. 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.

Nella fase di Transizione :

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

  1. 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.
  2. Eliminare tutte le interruzioni del sistema di avvio a causa di dati non corrispondenti.
    Un altro obiettivo espresso in termini di qualità.
  3. Raggiungere 2.000 transazioni al minuto.
    Miglioramento delle prestazioni con ottimizzazione del processo: modifica della struttura dati, memorizzazione nella cache e algoritmo definito maggiormente.
  4. Ridurre il numero di diverse caselle di dialogo del 30%.
    Migliorare l'utilizzabilità riducendo la distorsione visiva
  5. 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.
Definizione dei criteri di valutazione dell'iterazione

Ciascuna iterazione ha come risultato un rilascio eseguibile. Il rilascio non è solitamente una produzione di qualità (ad eccezione nell'iterazione di transizione finale), ciò nonostante più essere valutato.

Valutazione delle iterazioni di inizio validità

L'iterazione di inizio validità si concentra generalmente sulla verifica del concetto del prodotto e sulla realizzazione del supporto necessario per approvare il finanziamento del progetto. Di conseguenza, il rilascio dell'iterazione è generalmente un prototipo POC (proof-of-concept) funzionale che manca di un effettivo codice di implementazione per l'interfaccia utente. I criteri di valutazione sono orientati verso l'accettazione da parte dell'utente e le misurazioni qualitative.

In alcune circostanze, le difficoltà tecniche chiave devono essere superate all'inizio validità prima che venga fornito il finanziamento al progetto; in tal caso, i criteri di valutazione devono tenere conto di quanto detto.

Valutazione delle iterazioni di elaborazione

Le iterazioni di elaborazione puntano alla creazione di un'architettura stabile. Come risultato, i criteri di valutazione dell'elaborazione devono puntare ad accertare la stabilità dell'architettura. Le misurazioni che possono essere utilizzate sono:

  • Stabilità dell'interfaccia (o violazione)
  • La frequenza di modifica nell'architettura (confrontata a una previsione di architettura)
  • prestazioni della funzionalità chiave

L'obiettivo chiave è di garantire che le modifiche effettuate durante la fase di costruzione non comportino conseguenze negative in tutto il sistema rendendo necessaria un'eccessiva rilavorazione.

Valutazione delle iterazioni di costruzione e transizione

Le iterazioni di costruzione e di transizione sono misurate durante le verifiche tradizionali del software e la gestione delle modifiche come le frequenze di rilevamento degli errori, la densità dei difetti e le incidenze di violazione. L'attenzione in queste iterazioni si concentra sulla ricerca degli errori in modo che possano essere corretti.

Gli errori possono essere rilevati in diversi modi: esami e revisioni del codice, testi funzionali, test di prestazioni e di caricamento. Ogni tecnica è orientata verso l'individuazione di una particolare serie di difetti e ciascuna ha la propria ubicazione. Le specifiche su queste tecniche vengono discusse nella disciplina di test del RUP (Rational Unified Process).



Definizione delle attività di iterazione

Sulla base degli obiettivi dell'iterazione, è necessario selezionare la serie di attività da eseguire durante l'iterazione. Tipicamente, ciascuna iterazione effettuerà un passaggio parziale attraverso tutte le attività nel ciclo di vita del software:

  • Vengono selezionati i casi d'uso e gli scenari che provano la funzionalità richiesta
  • La funzionalità del caso d'uso (o scenario) viene ricercata e documentata
  • La funzionalità viene analizzata e assegnata tra i sottosistemi e le classi che forniscono la funzionalità richiesta.
  • Le classi e i sottosistemi sono progettati, implementati e verificati per unità
  • Il sistema è integrato e verificato interamente
  • Per i rilasci esterni (alpha, beta e GA) il prodotto è impacchettato in un formato che consente il rilascio e la transizione all'interno del proprio ambiente utente.

Il livello di esecuzione di queste attività varia con l'iterazione e la fase del progetto. Le singole discipline (Requisiti, Analisi & Progettazione, Test, ecc.) definiscono le attività generiche, che a loro volta sono adattate all'organizzazione durante la configurazione del processo.

Identificazione delle attività e dei prodotti di lavoro interessati

Una volta che gli scenari o i casi d'uso completi da sviluppare (più i difetti da correggere) sono stati selezionati e brevemente delineati, è necessario individuare quali sono i prodotti di lavoro che saranno implicati:

  • Quali classi devono essere rivisitati?
  • Quali sottosistemi sono implicati o anche creati?
  • Quali interfacce sono probabilmente da modificare
  • Quali documenti devono essere aggiornati

Quindi, estrarre dalle discipline del processo le attività interessate e collocarle nel piano. Alcune attività sono eseguite una volta per iterazione (esempio di seguito), alcune una volta per classe, per caso d'uso o per sottosistema (esempio). Collegare le attività alle relative dipendenze e assegnare un determinato impegno stimato. Molte delle attività descritte per il processo sono piccole abbastanza per essere completate da una persona o da un numero ridotto di persone in una questione di alcune ore fino ad alcuni giorni.

Ci si renderà conto che non esiste sufficiente tempo nell'iterazione per effettuare tutte le attività. Piuttosto che estendere l'iterazione (quindi estendendo il tempo di consegna finale o riducendo il numero di iterazioni), ridurre le ambizioni dell'iterazione. A seconda della fase di applicazione, rendere gli scenari più semplici e eliminare o disabilitare le funzioni.

Assegnazione delle responsabilità

Una volta definita la serie di attività per l'iterazione, è necessario assegnarla al team del progetto. A seconda delle risorse di personale disponibili e l'ambito dell'iterazione, le attività possono essere eseguite da una singola persona o da un team. Le revisione e gli esami sono ovviamente attività di team. Altre attività, come la preparazione dei casi d'uso o la progettazione e l'implementazione delle classi, sono assegnate a singole persone (tranne che nel caso dove un membro del team junior collabora con un membro del team senior che funge da guida).

In generale, la responsabilità di ciascun prodotto di lavoro è di una singola persona, anche se il lavoro è svolto da un team:

  • Casi d'uso
  • Sottosistemi
  • Classi
  • Test e piani di test
  • ecc.

Senza un uninco punto di riferimento, garantire la coerenza diventa quasi impossibile.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Considerazioni chiave

La pianificazione del progetto è un'attività in cui il responsabile di progetto crea un'istanza (e successivamente ne gestisce l'esecuzione) di uno specifico processo di consegna (consultare Work Prodotto: Processo di sviluppo) per il progetto. Si tratta di un'operazione spesso definita norma del processo.

Il processo con "istanza creata" è un piano di progettazione/iterazione/attività attivabile (include le attività ed i prodotti di lavoro effettivi per un progetto attuale).  E' possibile creare l'istanza di un processo di consegna mediante importazione di un Processo di consegna da Rational Method Composer in RPM (Rational Portfolio Manager) RPM) e quindi eseguendo dei lavori di creazione istanze duplicando le attività e operazioni che sono impostate su isRepeatable o hasMultipleOccurences, creando prodotti di lavoro reali con assegnazione di risorse reali ai ruoli, ecc. 

Ulteriori informazioni