Attività del progetto

Articolo
08/15/2011

Per utilizzare il più efficacemente possibile MSF for CMMI Process Improvement v5.0, è necessario organizzare il progetto in una serie di iterazioni, in genere per una durata di quattro fino a otto settimane. In questo modo, è possibile ridurre i rischi per il progetto provocati da variazioni correlate a requisiti e costi di implementazione. Una struttura iterativa per il progetto contribuisce notevolmente a soddisfare i requisiti di gestione dei rischi di CMMI.

Per ulteriori informazioni su CMMI, vedere Informazioni generali su CMMI.

All'inizio del progetto

Inizio del progetto

L'inizio include la definizione della visione del progetto, in cui viene dichiarato tutto ciò che gli utenti saranno in grado di eseguire al rilascio del prodotto.

Questa fase include anche l'impostazione del team, dell'infrastruttura e delle altre risorse e la definizione del processo di sviluppo.

Per ulteriori informazioni, vedere Inizio del progetto.

Pianificazione iniziale del progetto

La pianificazione del progetto include le attività seguenti:

Analisi dei requisiti in modo sufficientemente dettagliato per consentire la definizione di un piano. L'analisi può includere l'utilizzo di modelli dei requisiti, storyboard e altri strumenti che semplificano l'individuazione del sistema di lavoro.
Concepimento di una progettazione o un'architettura complessiva per il sistema. Se si prevede di utilizzare una piattaforma nuova per i membri del team, è necessario assegnare una certa quantità di tempo per provarla. Lo sviluppo sarà più lento nelle iterazioni iniziali.
Definizione dei requisiti come set di requisiti del prodotto incrementali di cui è possibile stimare approssimativamente lo sviluppo. La distinzione tra requisiti generali e requisiti del prodotto è importante e costituisce un'attività significativa. Per ulteriori informazioni, vedere Sviluppo di requisiti.
Esecuzione di un'assegnazione iniziale di requisiti del prodotto a iterazioni.
Impostazione delle date per le diverse versioni del prodotto.

Il piano e i modelli dei requisiti verranno riadattati e perfezionati durante tutto il progetto. Parte dello scopo dello sviluppo iterativo consiste nel consentire miglioramenti dei requisiti prodotti dalla dimostrazione del software funzionante in una fase iniziale.

La pianificazione iniziale del progetto viene eseguita nell'iterazione 0.

Per ulteriori informazioni, vedere Pianificazione del progetto (CMMI).

Esplorazione di un prodotto esistente

L'obiettivo del progetto potrebbe essere l'aggiornamento di un prodotto già esistente. In questo caso, se il team non ha familiarità con il prodotto, l'esplorazione del codice è un'attività per l'iterazione 0. Ogni attività di sviluppo nelle iterazioni successive comporterà anche la comprensione del codice in una posizione specifica e la tracciatura delle conseguenze della relativa modifica.

Per ulteriori informazioni, vedere Visualizzazione del codice esistente.

Durante il progetto

Il piano viene rivisto ed è soggetto a modifiche durante tutto il progetto.

Diverse attività correlate al piano del progetto vengono eseguite regolarmente durante tutto il progetto, in genere verso la fine di un'iterazione.

Convalida

Presentare ai clienti o alle parti interessate all'interno dell'azienda il software sviluppato durante l'iterazione. Se fattibile, rendere il software disponibile a tali soggetti perché lo provino o lo utilizzino appieno in un contesto pratico.

Dopo un intervallo sufficiente, organizzare una riunione per esaminare i commenti e i suggerimenti degli utenti. Tali commenti e suggerimenti devono essere utilizzati per generare richieste di modifica.

Per ulteriori informazioni, vedere Validating Customer Requirements.

Gestione dei rischi

Esaminare la probabilità e l'impatto di eventuali eventi avversi e adottare le misure per ridurre i rischi. Per ulteriori informazioni, vedere Gestione dei rischi.

Gestione delle modifiche

È possibile utilizzare elementi di lavoro richiesta di modifica per registrare le modifiche nei requisiti dichiarati dalle parti interessate all'interno dell'azienda. Tali modifiche possono essere prodotte da cambiamenti nel contesto aziendale, ma anche dalla dimostrazione e dalle prove delle versioni precedenti del prodotto. Queste modifiche devono essere accolte positivamente, in quanto consentono di migliorare l'idoneità del prodotto per gli scopi aziendali. Questo effetto è parte dell'obiettivo dello sviluppo incrementale.

Alcuni team del progetto modificano gli elementi di lavoro dei requisiti del prodotto quando vengono richieste le modifiche, senza utilizzare un elemento di lavoro distinto. Il vantaggio dell'elemento di lavoro richiesta di modifica, tuttavia, sta nel fatto che nella parte successiva del progetto sarà possibile esaminare il numero e la natura delle modifiche apportate. È possibile utilizzare queste informazioni per migliorare il processo o l'architettura per il futuro.

Le richieste di modifica devono essere utilizzate come input per la revisione del piano del prodotto.

Per ulteriori informazioni, vedere Gestione delle modifiche (CMMI).

Revisione del piano del prodotto

Eseguire una revisione del piano del prodotto prima di pianificare ogni iterazione. Il piano del progetto assegna requisiti del prodotto a iterazioni.

Il piano verrà modificato per due motivi principali:

Modifiche nei requisiti.
Modifiche nelle stime effettuate dagli sviluppatori. Con il progredire del progetto, il team di sviluppo può eseguire stime più affidabili delle attività necessarie per implementare funzionalità successive. In alcuni casi, è possibile che alcune funzionalità siano state posticipate da un'iterazione precedente, per l'aggiunta di una funzionalità al piano.

Entrambi i tipi di modifica diventano meno frequenti nelle iterazioni successive.

Rivedere i modelli dei requisiti da cui derivano i requisiti del prodotto.

Rivedere l'assegnazione dei requisiti alle iterazioni. Proprio come nell'attività di pianificazione iniziale, le parti interessate all'interno dell'azienda forniscono le priorità, il team di sviluppo fornisce le stime e la riunione cerca di distribuire le funzionalità tra le iterazioni.