Gestione delle modifiche
Il normale Ciclo di Sviluppo di un CSCI è suddiviso in n fasi, ad ogni fase tutti gli elementi di progetto sviluppati vengono valutati in un riesame formale che si conclude con uno dei seguenti esiti:
-
la fase i è completata: tutto l'output della fase (in revisione r) è congelato (baselined), la fase i+1 è formalmente aperta in revisione r.
-
La fase i è incompleta o deviata (non risponde ai requisiti qualitativi di verifica e validazione): tutto l'output della fase (in revisione r) dovrà essere rielaborato (corretto) tenendo conto dei problemi emersi durante il riesame e formalizzati nel Rapporto di Riesame ed in Segnalazione Anomalie Software. Tutto l'output della fase, con le modifiche introdotte, verrà sottoposto ad un nuovo riesame in revisione incrementata (revisione r+1).
-
L'output (in revisione r) della fase i evidenzia incompletezza e/o deviazione di una fase precedente (che non sia l'Allocated Baseline, ABL): lo sviluppo per quell'articolo deve essere riportato alla fase k < i (individuata dal Rapporto di Riesame) e le modifiche, formalizzate in Segnalazione Anomalie Software. Tutto l'output della fase k, con le modifiche introdotte, verrà sottoposto ad un nuovo riesame in revisione incrementata (revisione r+1).
-
L'output (in revisione r) della fase i evidenzia incompletezza/incongruenza dell'Allocated Baseline (ABL in versione v): lo sviluppo per quell'articolo deve essere riportato alla fase Analisi dei Requisiti, le modifiche sono formalizzate in richiesta / analisi / ordine di modifica. Tutto l'output della fase Analisi dei Requisiti, con le modifiche introdotte, verrà sottoposto ad un nuovo Riesame dei Requisiti (SRR) e successivo congelamento in ABL (quindi in stato "AUTORIZZATO") in versione incrementata (versione v+1) e revisione iniziale (r=0).
Nel caso che si verifichi b., c. o d., anche il POCP dovrà essere aggiornato per tener conto dell'introduzione delle modifiche (riesame priorità delle attività , ridistribuzione delle risorse).
Vi è inoltre la possibilità che condizioni di modifica indicate in b., c. e d. si inneschino al di fuori dell'attività di revisione formale pianificata: in un certo senso sono eventi asincroni all'iter normale di sviluppo (riesami informali e/o proposte esterne di modifica). Tali condizioni di modifica devono essere notificate tempestivamente al responsabile di progetto che analizza la proposta di modifica e ne valuta l'impatto sullo sviluppo, riconducendosi ad uno dei punti precedenti.