Skip to content.
Logo tecnoteca

Portale Tecnoteca.it

Logo tecnoteca

Vai al sito aziendale Tecnoteca.com


 

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:

  1. la fase i è completata: tutto l'output della fase (in revisione r) è congelato (baselined), la fase i+1 è formalmente aperta in revisione r.


  1. 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).

  2. 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).

  3. 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.

________________


Tesi di Laurea:
"Certificazione del software: problemi e metodi"

di Alessandro Febbo
________________

- Università delle Marche -
- Facoltà di Ingegneria -
- Marzo 2003 -

________________


scarica presentazione.ppt »