Scopo
|
Per definire il numero, tipo (skill, dominio), esperienza e qualità del personale richiesto per il
progetto
|
In base alle stime dell'impegno per il progetto, alla tempificazione richiesta, alla struttura organizzativa scelta e
alla mappatura dei ruoli, il responsabile di progetto determina il profilo del personale (il numero di risorse oltre
l'orario normale e l'insieme di skill) necessario per il progetto. La stima dell'impegno lavorativo per un progetto non
è ovviamente indipendente dalle dimensioni di un team, dall'esperienza, dagli skill e dalla qualità; in tutta
probabilità, il responsabile di progetto avrà fatto delle supposizioni circa la capacità del personale, ecc. durante la
realizzazione della stima dell'impegno. Nel modello di valutazione COCOMO (consultare Compito: Pianificazione delle fasi e dell'iterazioni), la capacità e
l'esperienza del personale sono i principali vettori dell'impegno. Pertanto, selezionando un impegno totale accettabile
(ottimizzando i diversi programmi di impegno COCOMO) e una tempificazione realizzabile determinerà il profilo del
personale.
In alcuni casi, il responsabile di progetto potrebbe conoscere in anticipo il numero e gli skill del personale che
saranno disponibili. In questi casi, con gli skill e il numero del personale definiti, solo la pianificazione è
variabile, supponendo che l'ambito del progetto resti costante.
Il responsabile di progetto deve prestare attenzione anche ai danni provocati dall'eccessiva rapidità di scalata dei
livelli di personale e il potenziale effetto catastrofico sulla produttività per tentare radicali riduzioni di
pianificazione, mediante un aumento considerevole del numero di risorse.
Durante la fase iniziale, l'attenzione si concentra sulla definizione e delimitazione dell'obiettivo e sullo sviluppo
di uno scenario di business per il progetto Di conseguenza, la dimensione del team è alquanto piccola: un responsabile
di progetto, un architetto di software e probabilmente uno o due sviluppatori, soprattutto dove è richiesto un
prototipo POC (proof of concept) per chiarificare i requisiti o il supporto di build per il prodotto.
Durante la fase di elaborazione, l'attenzione si concentra principalmente sull'architettura e sul prototipo
strutturale. Di conseguenza, le attività di progettazione nella fase iniziale di elaborazione si concentrano sugli
aspetti strutturali; poca attenzione viene attribuita ai dettagli delle classi e dei relativi attributi, che sebbene
identificati non sono significativi secondo l'architettura. Durante queste iterazioni, la maggior parte dell'impegno
proviene dal team di architettura e da un team per la realizzazione dei prototipi assegnato. Quest'ultimo team viene di
solito formato da programmatori molto esperti. A questo punto si dispone di un team di progettazione molto piccolo che
si concentrerà sulle tecnologie e sui meccanismi generici. Il gruppo di test si dedicherà alla realizzazione
dell'ambiente di test e alla verifica dei primi casi d'uso.
La scelta dei membri del team di architettura deve essere effettuata con attenzione: non solo devono possedere degli
skill di progettazione e di analisi superiori, ma anche delle qualità di leader. Per poter comunicare l'architettura al
team più grande durante la fase di costruzione, una buona prassi è distribuire i membri del team di architettura nel
team di costruzione. I membri del team di architettura devono anche avere acquisito un'elevata esperienza nella
progettazione del software: implementazione e progettazione del software, ottimizzazione delle prestazioni, gestione
del database, gestione della rete e della configurazione sono i principali skill richiesti nel team di architettura.
La fase di costruzione punta alla conservazione dell'integrità strutturale del sistema mentre viene realizzata una
funzionalità crescente all'interno del sistema. Ciò richiede un perfezionamento strutturale (da qui la "creazione di
una linea di base" e non il "blocco" dell'architettura seguente alla fase di elaborazione) e un team di architettura
che controlla i progettisti e le loro progettazioni.
Il personale del team di architettura tenderà ad integrarsi con i team di sviluppo, assumendo la funzione di
responsabili tecnici e coordinando le problematiche interne al gruppo con gli altri responsabili tecnici. Anche il
personale dei team di costruzione deve avere funzioni trasversali, sia con esperienze di progettazione che di sviluppo,
dal momento che è responsabile per la progettazione e l'implementazione della relativa funzionalità assegnata.
Tipicamente, un team di costruzione è responsabile per uno o più sottosistemi con interfacce ben definite; le modifiche
a queste interfacce o l'aggiunta di nuovi sottosistemi determinano una modifica strutturale e rendono necessario un
attento esame. All'interno del sottosistema, il team è relativamente libero di progettare e implementare secondo le
proprie vedute, ma è richiesta comunicazione tra i team per evitare che si realizzino in parallelo gli stessi
meccanismi di implementazione.
Tipicamente, i team di costruzione hanno un'organizzazione orizzontale, lungo le linee dei livelli. Un team può essere
responsabile delle interfacce di database o dell'infrastruttura di comunicazione, mentre gli altri team si concentrano
sulla funzionalità stessa dell'applicazione. I team di livello "superiore" di conseguenza necessitano di una maggiore
esperienza nel dominio del problema mediante la progettazione dell'interfaccia utente o interfacciando con i sistemi
esterni. I team di livello "inferiore" hanno più dimestichezza con la tecnologia di implementazione. La composizione di
questi team deve rispecchiare le seguenti diverse richieste di skill.
La prima domanda nell'ambito dei test è quante verifiche formali sono richieste? Inoltre, quanto tempo si può dedicare
a questa attività per poter soddisfare gli obiettivi di qualità e tuttavia essere ancora nei limiti ragionevoli da un
punto di vista economico e di pianificazione. E' raro che i progetti abbiano il budget necessario per effettuare tutti
i tipi di test. Tipicamente, i progetti devono selezionare un livello di test possono permettersi. Tenere presente che
ciascuna specifica di test deve essere esaminata e sostenuta. E' controproducente perlo stato d'animo del team di
progetto se esistono dei piani per creare molte specifiche di test, ma poi non è possibile implementarli perché si ha
poco tempo.
Creare uno specifico team di test. Almeno una persona nel team di test deve provenire dal team di acquisizione dei
requisiti. Il team di test è responsabile per:
-
Test black-box. Eseguire il test dei casi d'uso dall'esterno del sistema sulla base del flusso di eventi del
caso d'uso (consultare Prodotto di lavoro: Caso d'uso).
-
Test white-box. Eseguire il test dell'invio effettivo dei messaggi nel caso d'uso sulla base delle viste
sequenza per gli scenari.
-
Test di sistema. Sollecitare il sistema per rivelarne la vera natura.
Tenere presente che la verifica non si limita solo all'esecuzione dei test - l'attività include anche la preparazione
dell'ambiente di test e la scrittura e il controllo delle specifiche.
Un gruppo indipendente deve eseguire il test dei casi d'uso e dell'intero sistema. I componenti devono eseguire i test
e scrivere anche i report del test. L'attività di verifica dei casi d'uso deve essere organizzata in modo che vi sia
una persona responsabile per la verifica di ciascun caso d'uso.
Se non è possibile per un gruppo indipendente eseguire il test dei casi d'uso, poiché impegnato su un piccolo progetto,
occorre almeno essere certi che la persona responsabile della progettazione di un caso d'uso non esegua il test del
caso d'uso.
La verifica automatizzata della regressione deve essere effettuata su progetti medi e grandi. Il team di test
richiederà alcuni programmatori per supportare questa funzionalità. Ciò è anche più importante durante uno sviluppo
interattivo, dove non si intende impegnare troppe risorse rieseguendo le suite di test più volte.
Nella fase di transizione, l'attività di sviluppo è completata. Viene condotta la fase di verifica beta e preparata un
rilascio finale. Se è stato fatto un buon lavoro nella fase di costruzione, il team di progetto può iniziare a
ridimensionarsi, riducendo il numero di sviluppatori e di tester. La composizione del team inizierà a cambiare con
l'inserimento di istruttori e di esperti nella logistica d'infrastruttura che sono responsabili per la distribuzione
del prodotto nella comunità di utenti.
L'architetto di software o il team di architettura lavora in una "modalità supplementare": contribuisce ad ordinare i
report dei problemi, assegnare una priorità alle proposte di modifica e cambiare gli ordini per accertarsi che i
problemi non siano corretti per un motivo di convenienza in un modo che possa danneggiare l'architettura. Le attività
di progettazione tendono a ridursi durante la fase di transizione e sono limitate alla risoluzione dei problemi o
all'introduzione dei miglioramenti dell'ultimo minuto.
|