Configuration management

Configuration Management
Corso di Gestione dei Progetti Software
di
Francesco Garofalo,
Antonio Fasulo Prof.ssa F.Ferrucci

Perché il Configuration Management? 1/2
I sistemi software cambiano continuamente durante lo sviluppo e l’uso.
I sistemi SW grandi e complessi richiedono molti più cambiamenti rispetto a
sistemi di piccola taglia, e la gestione dei cambiamenti in sistemi di grandi
dimensioni è complessa e non banale.
Il concetto di Configuration Management (CM) è nato per gestire i
cambiamenti nei sistemi di grossa taglia.
La maggior parte dei sistemi può essere pensata come un insieme di versioni,
ognuna delle quali deve essere mantenuta e gestita.

Perché il Configuration Management? 2/2

Definizione
La Configuration Management riguarda le politiche, i processi e gli strumenti
per la gestione dei sistemi software in evoluzione.
La Software Configuration Management è stata definita da Bersoff, Henson e
Siegel come la disciplina che identifica la configurazione di un sistema in
momenti distinti nel tempo allo scopo di controllare sistematicamente i
cambiamenti e garantire l’integrità e la tracciabilità di ogni configurazione per
tutto il ciclo di vita.

Un po’ di storia 1/2
La CM nasce nel 1950 da un bisogno dell’industria aerospaziale, che aveva
necessità di garantire la riproducibilità degli aircraft e per la gestione
dell’ingegneria dei cambiamenti.
Negli anni 70 con la distribuzione dei
software e dei computer su larga scala, il
problema del configuration
management e change management si
inizia ad evidenziare sempre di più.
Per lo Univac 1100 exec-8 i
manutentori utilizzavano “card
correttive” di vario colore per
distinguerle.

Un po’ di storia 2/2
A cavallo tra gli anni 70 e 80, la SCM emerge come disciplina.
Con l’avanzamento dei software sempre più user friendly vennero costruiti dei
software specializzati per il build, come make e strumenti per il source code
control system (SCCS) e il revision control system (RCS) per permettere ai
manutentori di tenere traccia di tutte le alterazioni testuali effettuate nel file.

Benefici & Obiettivi 1/2
Il Configuration Management:
● assicura che lo sviluppo dei processi sia tracciabile e sistematico e che
tutti i cambiamenti siano gestiti precisamente;
● migliora la qualità dei sistemi rilasciati e la produttività dei manutentori;
Il CM è una parte essenziale dello sviluppo software e dell’ambiente di
manutenzione.
Assicura che il Software rilasciato non sia contaminato da cambiamenti
incontrollati e non approvati.

Benefici & Obiettivi 2/2
Gli obiettivi del CM sono:
● Identificare ogni versione del sistema;
● Conservare versioni precedenti di documentazione e software;
● Fornire una traccia di audit per tutte le modifiche effettuate;
● Per tutto il ciclo di vita, mantenere la tracciabilità e l’integrità del sistema.
I benefici del CM sono:
1. Ridurre la confusione e stabilire un ordine;
2. Assicurare che le attività siano ben organizzate al fine di mantenere
l’integrità del prodotto;
3. Garantire le corrette configurazioni del prodotto;
4. Garantire la qualità del software, e un software di qualità richiede
meno sforzi di manutenzione;
5. Migliora la produttività, poiché analisti e programmatori sanno
esattamente dove trovare ogni pezzo di software e di documentazione;
6. Riduce la responsabilità grazie ad una documentazione che traccia le
azioni;

Funzionalità del CM
Product

Identification
Identification 1/2
Gli item che necessitano della configurazione, devono essere identificati in questa
fase.
L’identificazione include specifiche, design, documenti, dati, disegni, codice
sorgente, codice eseguibile, test plan, componenti hardware, e componenti
software per lo sviluppo, altresì chiamati, compilatori, debugger ed emulatori.
Per identificare accuratamente i prodotti e le loro configurazioni e versioni è
necessario progettare una baseline di configurazione.

Identification
Identification 2/2

Version Control
Definizione 1/4
Per evitare confusione sugli artefatti durante il processo evolutivo, è necessario
assegnare un nuovo identificatore all’artefatto ogni volta che l’artefatto è
modificato;
È importante notare che assegnare un nuovo identificatore per ogni modifica allo stesso artefatto
potrebbe nascondere importanti relazioni tra gli artefatti identificati in modo univoco.
Ad esempio, si potrebbe essere interessati a registrare un fatto che un determinato
artefatto corregge un sottoinsieme di difetti rilevati in una versione precedente.
Il tipo di relazione di cui sopra può essere registrato mediante la funzionalità di
Version Control (VC) di SCM:
(i) interpretando gli artefatti software come elementi di configurazione e
(ii) identificando le relazioni, se ve ne sono, tra gli elementi di configurazione.

Version Control
Copie Master - Copie Funzionanti 2/4
L'idea di base del VC è di avere due file separati: copie master e copie funzionanti.
Il primo è archiviato in un repository centralizzato.
Gli sviluppatori di software controllano le copie funzionanti dal repository,
modificano le copie funzionanti e, infine, controllano le copie funzionanti nel
repository.
Il check-in in un file significa impegnarsi per le modifiche apportate alle copie
funzionanti, il sistema VC crea una nuova versione nella repository ogni volta che
viene eseguito il commit di un file.
Col passare del tempo, tutte le versioni del file vengono archiviate nel repository e
l’archiviazione di molte copie di un file non spreca eccessivamente spazio di
archiviazione

Version Control
Gestione dei conflitti 3/4
Possono sorgere conflitti se molti sviluppatori di uno stesso software desiderano
utilizzare la stessa versione di un file.
Tuttavia, i conflitti possono essere risolti mediante due tecniche:
● lock-modify-unlock
● copy-edit-merge

Version Control
Trunk, Branch e Merge 4/4

System models and selection
I file sono entità discrete che contengono descrizioni di elementi ben definiti di
un progetto, vale a dire specifica dei requisiti, casi di test, progettazione, codice,
risultati dei test e rapporti sui difetti. Tuttavia, non è né un mezzo efficiente né
efficace per le relazioni tra artefatti e attributi.
L’idea generale di configurazione solleva la necessità di consentire agli utenti di
avere un accesso selettivo a parti e versioni di tali manufatti aggregati. Per
impostazione predefinita, SCCS e RCS mantengono nell'area di lavoro la versione
più recente della variante principale.
Gli altri artefatti devono essere recuperati esplicitamente dall’utente

Tool

Workspace Control
Il Workspace è implementato nel SCM per offrire agli utenti un luogo isolato.
Nelle loro aree, gli utenti eseguono attività di modifica degli artefatti dove
possono testare isolatamente le modifiche effettuate.
Esistono due tipi di Workspace:
1. Simil Directory, dove viene effettuata la modifica diretta dei file
2. Workspace complessi, come ambienti di sviluppo integrato e database.
In generale un Workspace dovrebbe avere 3 caratteristiche fondamentali:
● Sandbox: I file devono essere modificabili nel workspace privato dell’utente;
● Building
● Isolation: Ogni sviluppatore deve avere un ambiente isolato in cui provare le
modifiche effettuate nel codice senza influire su altri utenti.

Change Management
Il Change Management ha lo scopo di garantire che la modifica sia un
processo gestito, dando maggior importanza alle richieste di cambiamento a
priorità più alta.
Il cambiamento è un dato di fatto per i grandi sistemi software e possono
derivare dai seguenti fattori:
● Scoperta di un bug;
● Richiesta di un nuovo requisito funzionale;
● Permettere a un sistema di adattarsi a diversi ambienti hw e sw

Change Management
Processo

Change Management
Change request
L’attività di change management inizia quando un cliente sottomette una change
request (CR):
● Segnalazione di un bug;
● Richiesta di una funzionalità aggiuntiva.
Queste problematiche spesso sono trattate separatamente all’interno di varie azienda,
ma sostanzialmente possono riferirsi al processo di change management.

Change Management
Change request - Statechart diagram
Una CR potrà assumere i seguenti stati (come descritti in figura) durante l’intero
processo di change management.

Change request (CR)
Una CR deve essere ben formattata all’interno di una Change Request Form (CRF).
Una CRF dovrà contenere:
● Raccomandazioni del
cambiamento;
● I costi/tempi stimati per la
modifica;
● Data richiesta del
cambiamento;
● Data di approvazione della
CR;
● Data implementazione
della CR;
● Data di validazione della
CR;
● Note.
Stato della CR : Submit

Change request
Validation
La CR deve essere poi validata per evitare le seguenti problematiche:
Stato della CR: Review
● CR già presa in carico;
● Fraintendimenti rispetto a quello che il cliente si aspetta e ciò che il sistema
offre;
● Funzionalità già esistenti nel sistema, ma che il cliente non ne conosce
l’esistenza.
Se una di queste condizioni fosse verificata, allora la CR verrà rigettata (Stato della
CR: Decline), altrimenti potrà passare alla fase successiva.

Change Management
Impact Analysis
A questo punto la CR deve essere valutata sotto un punto di vista di costo e tempo
necessario per la sua risoluzione.
Quest’attività generalmente è associata al team di sviluppo o di manutenzione, che
dovranno indicare quante componenti saranno impattate dalla CR e stabilire una
stima di quanto costerà tale modifica all’interno del sistema. Stato della CR: Analysis
Se il team di sviluppo non reputa fattibile
una determinata modificata, la CR verrà
rigettata. Stato della CR: Decline

Change Management
Approvazione
la decisione definitiva spetta al product development group che deciderà se
approvare la CR secondo le seguenti questioni:
● Quali saranno le conseguenze se non verrà accettata la CR?
● A chi è rivolta la CR?
● Quanto costa implementare la CR?
● Quando fare la CR?
Se la CR viene accettata verrà impostata anche la relativa priorità e verrà inserita
all’interno di uno stack (Stato della CR: Commit) dedicato alla gestione di tutte le
richieste di cambiamento, altrimenti Stato della CR: Decline.

Change Management
Implement change
Quando la CR deve essere processata, quindi implementata tutte le modifiche
apportate in ogni componente devono essere documentate all’interno di un derivation
history.
Stato della CR: Implement

Change Management
Review/Reporting
Al termine del processo di implementazione della CR, bisogna andare a svolgere le
seguenti attività, generalmente a carico del test manager Stato della CR: Verification:
● Testing delle funzionalità;
● Testing di regressione: importanti per garantire che la modifica apportata a
determinate componenti del sistema non ha intromesso errori in altre
componenti;
● Riportare i cambiamenti che sono stati effettuati con le relative nuove versioni
associate alle componenti modificate.
Se l’attività di test ha prodotto esito positivo allora Stato della CR: Closed, altrimenti
Stato della CR: Decline.

Release Management
Una release management è una versione di un sistema software che deve essere
distribuita ai clienti.
Perché definire il ‘quando’ effettuare una CR?
- Rilasci frequenti: utenti potrebbero non passare a una nuova versione,
soprattutto se devono pagare;
- Rilasci rari: utenti possono abbandonare il sistema, trovando maggior conforto
in altri sistemi alternativi.
Una release è un’attività molto costosa non solo per il lavoro tecnico necessario per
creare una nuova versione, ma anche per:
● Preparare il materiale pubblicitario;
● Definire strategie di mercato;
● File di configurazione (eventualmente per hw e SO differenti);
● Programma di installazione;
● Documentazione;

Release Management
Fattori di rilascio
I principali fattori di rilascio sono:
● Qualità del sistema: Se viene rilevato un grave bug del sistema deve essere previsto
un nuovo rilascio;
● Cambiamenti della piattaforma: Potrebbe essere necessario effettuare un nuovo
rilascio del sistema quando viene rilasciata una nuova versione del SO sul quale
opera il sistema;
● Competition: nuova versione causata dalla concorrenza;
● Requisiti di marketing: un’organizzazione potrebbe aver assunto un impegno
inerente a una pubblicazione in una determinata data;
● Sistemi personalizzati: i clienti forniscono e pagano per apportare determinate
modifiche ad un determinato sistema, che dovrà essere rilasciato il prima
possibile.

Variant Management
Per determinati sistemi molto spesso devono essere gestite varie varianti, come:
- varianti per vari utenti del sistema;
- varianti per varie piattaforme (deve girare su differenti sistemi operativi);
Due approcci per gestire le varianti:
● Redundant team: ad ogni team distinto è assegnata la gestione di una determinata
variante del sistema;
● Single project: cerca di massimizzare il codice che condiviso tra le varie varianti
creando un sotto-sistema principale condiviso da molti team.

System Building
Rappresenta l’attività di creazione di un sistema completo ed eseguibile,
compilando e collegando le varie componenti di un sistema, file di dati,
librerie esterne e file di configurazione.
Gli strumenti di Version Management (Vm)
e di system build devono comunicare con
un processo build che in relazione ad una
baseline di un determinato sistema,
provvede alla sua creazione.

System building
Interazione
La creazione di un sistema comporta l’assemblaggio di una grande quantità di
informazioni su software e sistema operativo, quindi ha senso andare ad utilizzare
tool automatici che automatizzano tale attività. Potrebbe essere necessario anche
aggiungere file di librerie o file di configurazione che definiscono l’installazione di
destinazione.

System building
Funzionalità
Un sistema di build deve prevedere le seguenti funzionalità:
● Version management system integration: il sistema di compilazione dovrebbe
controllare le versioni richieste dei componenti dal VM;
● Minimal recompilation: Il build system dovrebbe capire quali componenti
richiedono la compilazioni e quali risultano essere già compilate;
● Executable system creation: Il system build deve collegare l’oggetto compilato con
librerie e file di configurazione per creare un sistema eseguibile;
● Test automation: Alcuni sistemi di build possono automaticamente eseguire test
automatici usando tool di testing automatico come JUnit;
● Reporting: Fornire un rapporto positivo o negativo del build e dei test che sono
stati eseguiti;
● Documentation generation: Il system build potrebbe essere in grado di rilasciare
note inerenti al build su pagine di aiuto.

System building
Minimal recompilation
La compilazione essendo un’attività computazionale, i tool di system building sono
progettati con l’obiettivo di minimizzare il numero di componenti da compilare.
Bisogna trovare un modo per collegare un codice sorgente con il relativo codice
oggetto. Associare una firma ad ogni codice sorgente, che verrà riversata sul relativo
codice oggetto. Tale firma cambia ogni volta che il codice sorgente cambia e viene
ricompilato.

System building
Firme dei file
Possono essere usate due tipi di firme:
- Modification timestap: la firma del codice sorgente è l’ora e data in cui quel file è
stato modificato. Se il file del codice sorgente di un componente è stato
modificato dopo il file del codice oggetto correlato, il sistema presuppone la
ricompilazione per creare un nuovo file di codice oggetto;
- Source code checksum: la firma del file del codice sorgente è un checksum
calcolato dai dati nel file. Una funzione di checksum calcola un numero
univoco utilizzando il testo sorgente come input. Se si modifica il testo
sorgente anche di un carattere questo genera un checksum diverso. Puoi quindi
essere sicuro si quel codice sorgente, in quanto file con checksum diversi sono
in realtà diversi. Il checksum viene calcolato prima della compilazione e il
compilatore dopo la compilazione firma il codice oggetto con appunto il
checksum che è stato calcolato.

Process (Accounting & Auditing)

Status Accounting
Al fine di quantificare le proprietà del software è necessario raccogliere
statistiche.
Lo scopo dell’Accounting è:
1. Compilare e conservare registri formali sulle configurazioni esistenti;
2. Produrre report periodici sullo stato delle configurazioni, per fare questo è
necessario:
a. Descrivere correttamente il prodotto;
b. Verificare la configurazione per i test e la consegna;
c. Mantenere una storia di CR, incluse quelle approvate e quelle respinte;
Lo Status Accounting è utile per comunicare dettagli importanti del progetto e
elementi di configurazione agli stakeholder del progetto.

Auditing
I sistemi basati su CM devono fornire le seguenti funzionalità di Auditing:
1. Possibilità di ripristinare il sistema ad un punto stabile precedente;
2. Identificare quali modifiche sono state eseguite, perché e chi le ha eseguite.
SCM viene così visto come un archivio ricercabile.
Prima di rilasciare un prodotto è
necessario effettuare:
1. Audit per la configurazione
formale
2. Audit per la configurazione fisica

IEEE 828-2005
IEEE Standard for Software Configuration Management Plans
IEEE Std 828-2005 was prepared by the Life Cycle Data Harmonization
Working Group of the Software Engineering Standards Committee of the
IEEE Computer Society. This revision is a minor update to IEEE 828-
1998 and was done to ensure consistency among the SCM guidance
provided by this standard, IEEE/EIA 12207.1 TM -1997, IEEE/EIA
Guide for Information Technology—Software Life Cycle Processes — Life
Cycle Data, and the IEEE Software Engineering Body of Knowledge
(SWEBOK) project. Information regarding relationships of IEEE 828-
2005 to other standards is contained in Annex B.
Lo standard in uso attualmente è IEEE 828-2012

IEEE Std 828-2005
Template
1. Overview
2. Definitions and acronyms
3. The Software Configuration Management Plan
4. Adaption the plan
5. Conformance to the standard

IEEE Std 828-2005
1.Overview
1. Overview
1.1 Scope
Questo standard stabilisce i contenuti minimi richiesti da un Software
Configuration Management Plan (SCM). Questo standard si applica
all'intero del ciclo di vita di software critici; ad esempio, laddove il
fallimento avrebbe un impatto sulla sicurezza o causerebbe grandi
perdite finanziarie o sociali. Si applica anche al software non critico e al
software già sviluppato.
1.2 Purpose
Il piano SCM documenta quali attività SCM devono essere svolte,
come devono essere svolte, chi è responsabile di svolgere attività
specifiche, quando devono accadere e quali risorse sono necessarie.
Può indirizzare le attività SCM su qualsiasi parte del ciclo di vita di un
prodotto software.

IEEE Std 828-2005
2.1 Definitions
2.2 Acronyms

IEEE Std 828-2005
Le informazioni sulla pianificazione di SCM devono essere suddivise nelle
sei classi descritte nella Tabella di seguito. Questa sezione deve contenere
tutte le informazioni sulla pianificazione di SCM mediante inclusione o
riferimento ad altre posizioni, ad esempio altri documenti.

IEEE Std 828-2005
3.1 Introduction
Le informazioni introduttive forniscono una panoramica generale e
semplificata delle attività SCM; in particolare chi approva, chi esegue e
chi interagisce con il SCM possa ottenere una chiara comprensione del
Piano.
3.2 SCM management
Il SCM management identifica le responsabilità e autorità per le attività
di SCM all’interno della struttura del progetto.
Le informazioni sulla gestione di SCM devono includere quattro
argomenti: l'organizzazione di progetto a cui applicare SCM, le
responsabilità di SCM di tali organizzazioni, i riferimenti alle politiche
e alle direttive SCM che si applicano a questo progetto e la gestione del
processo SCM.

IEEE Std 828-2005
3.2 SCM management
3.2 SCM management
3.2.1 Organization
Deve essere descritto il contesto organizzativo, tecnico e
gestionale, all'interno del quale devono essere realizzate le attività
SCM pianificate.
3.2.2 SCM responsibilities
È necessario specificare l'assegnazione delle attività SCM alle unità
organizzative. Per ogni attività elencata all'interno delle attività
SCM (nel punto 3.3), deve essere fornito il nome dell'unità
organizzativa che svolge una determinata attività.
Deve essere fornita una matrice che metta in relazione le
organizzazioni, le attività e le responsabilità.

IEEE Std 828-2005
3.2 SCM management
3.2 SCM management
3.2.3 Applicable policies, directives, and procedures
Eventuali vincoli esterni posti sul Plan da altre politiche, direttive
e procedure, devono essere identificati e per ciascuno di loro,
devono essere indicati impatto ed effetto sul Plan.
3.2.4 Management of the SCM process
a. Il costo previsto del processo SCM e il monitoraggio dei
costi;
b. I mezzi e costi per l’unità che dovrà sorvegliare la riuscita del
SCM;
c. L'identificazione, la valutazione e i piani per l'attenuazione dei
rischi associati allo svolgimento delle attività SCM.

IEEE Std 828-2005
3.3 SCM activities
3.3 SCM activities
Le informazioni sulle attività di SCM identificano tutte le funzioni e le
attività necessarie per gestire la configurazione del sistema software
come specificato nell'ambito del Piano. Devono essere identificate le
attività SCM sia tecniche che gestionali.
3.3.1 Configuration identification
3.3.1.1 Identifying configuration items
3.3.1.2 Naming configuration items
3.3.1.3 Acquiring configuration items
3.3.2 Configuration control
a) Identificazione e documentazione di un cambiamento
b) Analisi e valutazione di una richiesta di modifica
c) Approvazione o disapprovazione di una richiesta
d) Verifica, implementazione e rilascio di una modifica

IEEE Std 828-2005
3.3 SCM activities
3.3.2.1 Requesting changes
3.3.2.2 Evaluating changes
3.3.2.3 Approving or disapproving changes
3.3.2.4 Implementing changes

IEEE Std 828-2005
3.3.3 Configuration status accounting
3.3.3 Configuration status accounting
Le attività di status accounting registrano e riportano lo stato degli
elementi della configurazione del progetto.
Il piano deve contenere informazioni su quanto segue:
a) Quali elementi di dati e metriche SCM devono essere tracciati e
segnalati per baseline e modifiche;
b) Quali tipi di rapporti contabili sullo stato devono essere generati e la
loro frequenza;
c) In che modo le informazioni devono essere raccolte, archiviate,
elaborate, segnalate e protette dalla perdita;
d) Come controllare l'accesso ai dati di stato.

IEEE Std 828-2005
3.3.4 Configuration evaluation and reviews - Audit
3.3.4 Configuration evaluation and reviews
La valutazione della configurazione consiste in audit che determinano
la misura in cui il CI riflette le caratteristiche fisiche e funzionali
richieste.
L’Audit della configurazione sono un meccanismo di gestione per
valutare la baseline.
Il piano deve identificare gli audit di configurazione e le revisioni da
svolgere per il progetto.

IEEE Std 828-2005
3.3.5 Interface control - 3.3.6 Vendor Control
3.3.5 Interface control
Le attività di controllo dell'interfaccia coordinano le modifiche agli
elementi della configurazione del progetto con le modifiche
all'interfaccia degli elementi al di fuori dell'ambito del piano. HW, SW
di sistema e SW di supporto, nonché altri progetti e risultati,
dovrebbero essere esaminati per potenziali effetti di interfacciamento
sul progetto.
3.3.6 Subcontractor/vendor control
Le attività di controllo del fornitore incorporano gli elementi sviluppati
all'esterno dell'ambiente di progetto negli CI del progetto.
Sono inclusi software sviluppato per contratto e software acquisito
nella sua forma finita. Particolare attenzione dovrebbe essere rivolta a queste
attività SCM a causa delle relazioni organizzative e legali aggiunte.

IEEE Std 828-2005
3.3.7 Release management and delivery
3.3.7 Release management and delivery
L'SCMP descriverà come sarà formalmente controllata la costruzione,
il rilascio e la consegna dei prodotti software e della documentazione.
Le procedure per compensare le deviazioni e le deroghe approvate
dovrebbero essere incluse nei meccanismi di controllo. Copie master di
codice e documentazione devono essere conservate per tutta la vita del
prodotto software. Il codice e la documentazione che contengono le
funzioni essenziali di sicurezza che devono essere gestite, archiviate,
imballate e consegnate in conformità con le politiche delle
organizzazioni coinvolte.

IEEE Std 828-2005
3.4 SCM schedules - 3.5 SCM resources
3.4 SCM schedules
Le informazioni sullo schedule del SCM stabiliscono la sequenza e il
coordinamento per le attività SCM identificate e per tutti gli eventi che
incidono sull'attuazione del piano.
3.5 SCM resources
Le informazioni sulle SCM resources identificano l'ambiente,
l'infrastruttura, gli strumenti software, le tecniche, le attrezzature, il
personale e la formazione necessari per l'implementazione delle attività
SCM specificate.

IEEE Std 828-2005
3.6 SCM plan maintenance
3.6 SCM plan maintenance
Le informazioni sulla manutenzione del piano SCM identificano le
attività e le responsabilità necessarie per garantire una pianificazione
SCM continua durante il ciclo di vita del progetto. Il piano deve
includere una cronologia delle modifiche apportate al piano e indicare
quanto segue:
a) Chi è responsabile del monitoraggio del Piano
b) Con quale frequenza devono essere eseguiti gli aggiornamenti
c) Come devono essere valutate e approvate le modifiche al Piano
d) Modalità di modifica e comunicazione del Piano

IEEE Std 828-2005
4. Adapting the plan
4. Adapting the plan
Questo standard consente una notevole flessibilità nella preparazione
di un piano SCM. Un piano di successo riflette il suo ambiente di
progetto. Dovrebbe essere scritto in termini familiari ai suoi utenti e
dovrebbe essere coerente con i processi di sviluppo e
approvvigionamento del progetto.
4.1 Upward adaptation
4.2 Downward adaptation
4.3 Format

IEEE Std 828-2005
5.1 Minimum information
Le aree di attività definite nel punto 3 sono state definite
correttamente?
5.2 Presentation format
Deve esistere un documento, un titolo di sezione o tale riferimento che
sia specificamente etichettato "Piano di gestione della configurazione
del software". All'interno di questo documento, deve essere inclusa
ciascuna delle sei classi di informazioni.
5.3 Consistency criteria
5.4 Conformance declaration

Riferimenti
Slide di F.Garofalo & A.Fasulo
Libri:
● Software Evolution and Maintenance “A practitioner’s Approach” - P.Tripathy,
K.Naik;
● Software Engineering 9ed - Sommerville;
Articoli:
1. How is Configuration Management in Aircraft Industry implemented?
http://laccei.org/LACCEI2009-Venezuela/p89.pdf
2. SCMP 828-1983 - IEEE Standard -
https://ieeexplore.ieee.org/document/7439689
https://standards.ieee.org/standard/828-2005.html
https://ieeexplore.ieee.org/document/6170935
5.
https://www.researchgate.net/publication/220403673_Impact_of_software_engin
eering_research_on_the_practice_of_software_configuration_management

Configuration management

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to Configuration management

Similar to Configuration management (20)

More from Francesco Garofalo

More from Francesco Garofalo (6)

Configuration management