Gestion de configuration

Petit guide mthodologique (1re partie)

Square des Utilisateurs
La premire partie de ce guide mthodologique prsente les concepts de la gestion de configuration, applicables la matrise des systmes dinformation. Elle dresse un tableau des proccupations et des enjeux. Une seconde partie, publie dans la LETTRE 45, recensera les mthodes et les techniques utilises par cette discipline.

Introduction
Une production industrielle efficace repose :

sur

la connaissance des caractristiques des composants (matires premires et pices lmentaires) qu'elle doit transformer et assembler ;

sur la matrise des oprations qui commandent ces transformations et ces assemblages.
La gestion de production industrielle est l'ensemble des mthodes et des techniques qui permettent de matriser :

la nomenclature des composants ; les gammes de fabrication.

De faon analogue, la production de systmes d'information assemble des composants (plates-formes, progiciels, rseaux, modules de programmes, description de fichiers, langage de commande etc.). La gestion des diffrents tats d'un systme s'appelle la gestion de configuration. La gestion de configuration consiste mettre en uvre et utiliser des moyens organisationnels, techniques et administratifs pour obtenir, tout moment du cycle de vie du produit, une visibilit satisfaisante du produit, au travers de ses caractristiques physiques et fonctionnelles, gnralement dcrites dans des documents. La gestion de configuration est une discipline fondamentale pour les entreprises qui dveloppent des logiciels complexes de taille importante. Elle est incontournable pour les distributeurs de progiciels. Ces produits sont raliss en diffrentes versions adaptes aux caractristiques techniques et organisationnelles des divers sites sur lesquels ils seront installs, ce qui oblige le distributeur matriser la configuration de chaque installation. Cette gestion est rendue ncessaire par le besoin de fournir un systme cohrent, quelles que soient les modifications subies par ses diffrents composants. Cette gestion implique l'utilisation d'outils adapts qui permettent de grer, de suivre et de contrler toutes les volutions de chaque lment du systme, en parfaite cohrence avec des normes et des rgles prtablies. On distingue deux sortes de gestion de configuration et de modifications.

Une

gestion de configuration dynamique, ou adapte au dveloppement permet, essentiellement, de coordonner les activits de dveloppement des quipes, de suivre chaque composant logiciel au cours de son laboration jusqu' sa validation.

Une gestion de configuration statique, ou adapte la maintenance, archive les composants

d'un systme en production, contrle et trace ses modifications. Cette activit inclut la gestion des diffrentes versions du systme, la gestion des sites; elle se prolonge par la gestion des livraisons, voire la gestion de la rutilisation. Le prsent document traite essentiellement le thme de la gestion de configuration en phase de dveloppement.

La Lettre d'ADELI n44 Juillet 2001

13

Dfinitions
Les articles composants un systme d'information
Un systme d'information se compose :

d'un ensemble de plates-formes (machines et logiciels de base) ; d'un ensemble de logiciels applicatifs ; d'une organisation dcrite dans des procdures ; de documentations techniques et d'utilisation.
La norme ISO 10 007 : 1995 dfinit le terme article de configuration comme :

un ensemble de matriels, de logiciels, de produits, issus de processus caractre continu, de

services ;

ou un sous-ensemble dfini de ceux-ci ; qui a t retenu pour la gestion de configuration et qui est trait comme une seule entit dans le
processus de gestion de configuration. La notion d'article de configuration est une notion gigogne. Un systme se compose d'articles de configuration, eux-mmes constitus d'articles de configuration. Ainsi, dans le prsent guide mthodologique, nous emploierons labrviation article pour dsigner tout composant d'un systme d'information : lment matriel, module de programme, squence de langage de commande, document, poste de travail.

Les modifications d'un systme

Une modification est un changement qui n'altre pas la finalit d'un article. Les modifications jalonnent la vie du systme d'information, pendant deux priodes bien diffrencies. Pendant la priode de dveloppement, on conoit, on ralise et on installe le systme. Pendant la priode de production, on exploite le systme pour saisir, conserver, transformer et restituer les donnes ncessaires la gestion de l'entreprise. On peut classer les modifications selon leur origine.

Modifications correctives en rparation dincidents :

correction danomalies bloquantes ou majeures ; "# amliorations mineures (prsentation, lisibilit). "#

Modifications volutives demandes par l'utilisateur :

pour pallier un oubli ou une ambigut de spcification ; "# pour s'adapter de nouveaux besoins. "#

Modifications adaptatives imposes par les contraintes des environnements :

pour amliorer les performances (conomie de place, gain de temps) ; "# pour sadapter aux nouveaux environnements techniques et organisationnels. "#

Les volutions d'un systme

Chaque modification peut entraner une cascade de consquences sur les diffrents articles qui constituent le systme. En particulier (et c'est une consquence fcheuse si on n'y veille pas) toute modification risque de crer des incohrences entre les articles du systme. Par exemple, modifier, en urgence, un programme sans mettre jour la documentation technique correspondante, cre une incohrence entre le programme et sa documentation.

14

La Lettre d'ADELI n44 Juillet 2001

Les tats Chaque modification d'un article, aussi minime soit-elle, cre un nouvel tat de cet article. Un article, en cours de transformation, passe par une squence continue d'tats conscutifs. La conservation dtats transitoires, extrmement fugaces (modifications successives d'un module au cours de sa mise au point) ne prsente aucun intrt. Les rvisions d'un article lmentaire Certains tats sont considrs comme stables : par exemple un module qualifi, test avec succs et convenablement document. Ces tats seront figs pour tre conservs et consults ultrieurement. Une rvision est un tat d'un article dont la conservation prsente un intrt en raison de la dure prvisionnelle de stabilit de cet article. La conservation de cet tat identifi (par un indice de rvision) impose sa validation, son archivage (description de l'action ayant provoqu cet tat, rang de cet tat dans la vie de l'article, auteur, date, brve description du contexte). Les branches On appelle branche (ne d'une alternative) chaque rvision indpendante issue d'une mme origine (tronc). Pour identifier chacun de ces tats, il faut adjoindre au concept de rvision, la notion de branche. Ainsi, un instant donn de son dveloppement, plusieurs tats concurrents d'un mme article peuvent cohabiter. Il conviendra d'viter la prolifration des branches et de procder des fusions pour limiter le nombre de rvisions utiles. Les versions d'un systme Une version d'un systme est un ensemble cohrent de rvisions ncessaires et suffisantes pour rpondre un besoin prvisible. La conservation d'une version, identifie par un numro de version, impose l'archivage de la nomenclature des composants qui constituent cette version.

Les configurations d'un systme

Une configuration dcrit les lments d'un systme, en prcisant les diffrents articles composants et leurs liaisons. Elle constitue la rfrence d'une nomenclature d'un systme, un instant donn, en indiquant la liste des rfrences de ses articles constituants. Une configuration se caractrise par :

une identification ; une description ; une liste de composants (chaque composant tant dans un indice de rvision) ; une disposition relative de ces composants.
La gestion de configuration est la discipline qui permet de contrler l'volution d'un systme, durant les diverses phases de dveloppement et de maintenance et d'assurer l'intgrit et la cohrence des versions livres. Elle met en uvre des mthodes, des moyens et des outils qui permettent de grer efficacement :

l'identification ; la production ; le contrle ; le suivi de l'tat :

des constituants logiciels, "# de la documentation, "# des supports, "# ainsi que de tous les outils ncessaires leur dveloppement et leur exploitation. "#

La Lettre d'ADELI n44 Juillet 2001

15

Le contexte de la gestion de configuration

Les objectifs
Un projet d'intgration de systmes conoit, ralise et installe un ensemble applicatif cohrent. Chaque projet coordonne, au cours de son cycle de vie, un ensemble d'articles logiquement associs les uns aux autres. La gestion de configuration d'un systme d'information est une discipline dont les objectifs fondamentaux sont :

l'identification des articles et de leurs relations ; le contrle des volutions de ce systme durant les diverses tapes et phases du cycle de vie de
dveloppement et de maintenance ;

la

mise en place d'un processus d'archivage (rvisions successives des articles et de leurs dpendances, en synchronisation avec les modifications) ;

la traabilit de toutes les volutions au cours du cycle de vie ; la construction de versions livrables ; la vrification de la compltude et de la cohrence des versions livrables ; les ditions des rapports ncessaires l'utilisation des diffrentes versions (tapes du systme)
leur contrle, au suivi d'activit. La gestion de configuration conserve la mmoire de tout ce qui est cr, valid, avec la trace des vnements dclencheurs. La mmoire peut utiliser un support papier (documentation organise de faon rpondre toute question) ou un support informatique (fichiers, liens entre les fichiers, textes etc.) Cette activit concerne les programmes (sources et ventuellement excutables) dont le systme est constitu, mais elle doit prendre en compte galement :

la documentation ; les manuels ; les procdures ; les enchanements ; les jeux d'essais.
En rsum, la gestion de configuration doit matriser tous les lments associs au systme et dont il faut contrler l'volution et assurer la cohrence, y compris la nomenclature des lments matriels.

Les enjeux
La gestion de configuration assure une continuit dun systme, en dpit de toutes les modifications survenues au cours de sa vie, tant en dveloppement qu'en production. Il faut connatre l'tat de chaque article, tout instant, ainsi que son rle dans les phases du cycle de ralisation, de faon coordonner les phases de son dveloppement. Il faut tre en mesure de construire, avec rapidit et scurit, des systmes livrables offrant les mmes fonctionnalits sur des sites qui comportent des diffrences techniques (dploiement en environnement htrogne). Il faut pouvoir garantir la qualit des contrles de chaque article inclus dans un systme livrable.

16

La Lettre d'ADELI n44 Juillet 2001

Le contexte
L'ingnierie de systmes comporte :

le dveloppement (conception, construction et tests du systme, mise en uvre) de la solution ; le dploiement ventuel sur plusieurs sites homognes ou htrognes ; lexploitation ; la maintenance :
corrections d'anomalies ; "# adaptation aux volutions d'environnement technique ; "# adaptation aux volutions de l'activit de l'entreprise. "# Un systme est constitu d'un grand nombre d'articles de nature diffrente (modules de programme, description de donnes, documentation, jeux d'essais etc.). Ces articles possdent de nombreuses relations, les uns avec les autres. Plusieurs rvisions successives du mme article peuvent coexister :

un instant donn ; en plusieurs lieux distincts.

Le dveloppement de systmes d'information de grande taille, en un temps limit, appelle la collaboration d'un grand nombre de contributeurs travaillant en quipe. Ainsi, les composants du systme sont construits et assembls par des acteurs qui doivent coordonner leurs interventions autour d'articles communs.

La typologie des articles grs

Pour grer convenablement le dveloppement d'un systme, il faut tout d'abord le modliser par une architecture de composants relis les uns aux autres. Pour ce faire, on dfinit des articles et de rgles de dpendance dont l'ensemble constitue le systme rsultant du dveloppement. Toutes les mthodes de gestion de configuration proposent une telle dcomposition, caractrise par un niveau de prcision et d'exhaustivit. Malheureusement, le plus souvent, cette dcomposition n'est dfinie qu' partir des seuls lments physiques tels que les fichiers les rpertoires, sur lesquels sont plaqus des usages et des conventions (rgles de nommages, structuration du logiciel). Le systme applicatif constitue l'essentiel d'un systme d'information, sous ses diffrentes formes :

modules en langage source ; modules excutables (binaires gnrs) ; squences de commande (JCL langage de commande) ; description des donnes ; documentation ;
dossier du projet : "# plan projet, plan dassurance qualit, spcifications dobjectifs, spcifications externes, dossier de conception technique gnrale et dtaille, documentation technique : "# manuel d'installation, manuel d'utilisation,

essais :

protocole de recette, "# cahier de recette, "# jeux d'essais, "# rsultats des essais, "#

La Lettre d'ADELI n44 Juillet 2001

17

 tats des plates-formes :

dveloppement, "# exploitation. "# Les articles grs ne sont pas indpendants mais groups en configurations de rfrence (ensembles complets et cohrents d'articles logiquement relis). Certains articles prsentent des particularits. Articles drivs

Un article driv est un article gnr (quelquefois automatiquement) partir d'un autre article
(exemple code binaire gnr partir du langage source). Articles accessoires jeux d'essais et la documentation sont des articles qui s'appliquent d'autres articles (modules, sous-systmes etc.). Articles composites

Les Ce

sont des regroupements d'articles (par exemple, une chane de programmes regroupe un ensemble de programmes associs par une squence en langage de commande).

Les inquitudes
Le chef du projet se pose les questions suivantes, relativement la matrise des configurations :

comment s'assurer de l'utilisation de l'article adquat dans la rvision souhaite ? comment scuriser cet article en garantissant son intgrit ? comment organiser l'volution des articles, au cours du cycle de vie ? comment contrler la cohrence de la fourniture des articles de l'application
environnements de dveloppement vers le ou les environnements d'exploitation, cible ?

des

comment suivre l'avancement de la ralisation des modifications ? comment connatre l'auteur de la modification ?
Il veut pouvoir rpondre aux questions suivantes :

quelle est l'identification de l'article (fichier, composant, etc.) ? est-il en cohrence avec les articles dpendants ? quelle est sa dernire rvision ? fait-il partie de la livraison ? est-il mis en rfrentiel (archive) ? en existe-t-il d'autres rvisions ou versions ? dans quel environnement doivent-ils tre exploits ? etc.
Les exigences
Il faut pouvoir identifier, sans ambigut, chaque article composant du systme. C'est ce que l'on appelle la nomenclature. Tous les articles doivent tre identifis :

logiciels applicatifs, interfaces, jeux d'essais (donnes, JCL etc.) ; mais aussi les documentations de spcification, de ralisation, d'essais etc.
Mais, les articles, grs en configuration, ne le sont pas tous de la mme faon :

les contenus de certains articles sont grs en configuration (programmes) ; pour d'autres articles, des identifiants rfrencent des contenus grs
(description de matriels standard).

de faon externe

18

La Lettre d'ADELI n44 Juillet 2001

Un premier travail doit :

identifier les articles que l'on dsire grer ; dfinir les tats qui seront conservs ; mettre en place une nomenclature simple.
Les responsabilits
La gestion de configuration s'intgre dans le plan de dveloppement du projet. La rigueur de gestion de configuration apparat de plus en plus ncessaire, au fur et mesure de l'avancement des travaux ; elle devient incontournable lors des ralisations et des premires recettes. La gestion de configuration est l'un des constituants de l'organisation du projet ; la matrise des configurations relve clairement de la responsabilit du chef de projet. Cependant, pour des projets importants, le chef de projet peut dlguer cette responsabilit un administrateur nommment charg de la gestion de configuration. Le mme administrateur peut assurer la mission globale de gestion de configuration, tout ou long du projet ; mais, sa responsabilit peut aussi se limiter une seule tape. Dans la suite de ce document, nous dsignerons le responsable de la fonction de gestion de configuration par le terme administrateur, quel que soit son statut : chef de projet ou son dlgu.

Les solutions
La place de la gestion de configuration dans un projet
La gestion de configuration mmorise les descriptions statiques du systme chaque stade de son dveloppement. La vision dynamique rsulte d'une mise en perspective de successions de descriptions statiques dans le temps. Chaque stade de l'volution peut tre accessible. La conservation des vnements dclencheurs permet de reconstituer toute la vie du projet, de faon discontinue, au rythme des validations. Il faut dresser l'inventaire de tous les rsultats conserver pour toutes les phases et pour toutes les tapes. Pour chaque tat conserv (rvision), il faut connatre :

l'article ; l'auteur ; l'vnement dclencheur ; la validation qui dclenche la conservation ; la date de conservation.
La planification fournit le descriptif des tches et leur synchronisation, et indique ainsi :

les tats stables attendus (rvisions) ; les vnements dclencheurs (descriptifs) ; les liens entre toutes les rvisions qui constituent une version.
La gestion des ressources, dtermine : et formes) mis en uvre pour chaque tche et rsultat en indiquant l'ordre et lieu de rangement. Ceci dtermine :

les acteurs et leurs fonctions ; les moyens techniques (supports les poste de travail ; le lieu de rangement ;

armoire (pour les documents crits) ; "# bibliothque (pour les supports informatiques) ; "#

l'organisation

des phases ou tapes (environnement de dveloppement, dintgration, de validation, dexploitation, support externe, etc.).

La Lettre d'ADELI n44 Juillet 2001

19

La gestion de configuration doit respecter les mthodes, les normes et les standards prconiss pour le dveloppement du systme.

Les caractristiques essentielles

Chaque systme est soumis des contraintes particulires. Il rpond des besoins spcifiques, tout en respectant les usages des acteurs. Son dveloppement et sa maintenance s'effectuent dans des environnements varis (mthodologie, technologie, management). La gestion de configuration interagit avec dautres activits de dveloppement et dexploitation de systmes :

conception de la solution ; construction et tests du systme ; validation ; mise en uvre et exploitation de la solution ; assurance de la qualit ; gestion de projet.
Les choix mthodologiques et organisationnels crent des contraintes pour la gestion de configuration et, inversement, les dcisions prises concernant la gestion de configuration imposent des contraintes aux autres activits. Certains projets appliquent, des standards qui imposent des rgles strictes sur la gestion des configurations, telles que :

nomenclature d'identification des articles ; vocabulaire (rvision, version etc.) ; format des documents de suivi de l'volution ; normes de programmation ; procdures de contrle ; contrle de l'accs des utilisateurs ; etc.
Pour toutes ces raisons, il n'est pas concevable qu'une mme gestion de configuration puisse convenir tous les cas d'utilisation. Ds le lancement du dveloppement, l'administrateur des configurations et des modifications doit tenir compte du degr de la flexibilit requise et des contraintes imposes, en adaptant le modle de base. La gestion de configuration offre les services suivants :

reconnaissance des acteurs et gestion des accs ; archivage des articles ; gestion des rvisions des articles et des versions des systmes ; contrle de la gestion du projet l'aide de rapports dtaills ; traabilit de toute l'activit grce une journalisation rgulire des rvisions et des versions,
l'dition et l'exploitation d'historiques ;

contrle de la cohrence des configurations ; diffusion, de faon constante et reproductible, des modules en langage source pour compilation,
assemblage, mise disposition des documentations correspondantes.

20

La Lettre d'ADELI n44 Juillet 2001

Les principales fonctions

La gestion des espaces de dveloppement Les articles sont grs en configuration tout au long de leur existence. Les dveloppeurs faonnent des articles qui voluent d'un tat initial, embryonnaire, partiel, un tat cohrent, complet, livrable. Un article peut exister dans plusieurs espaces diffrents au cours de sa vie (poste du dveloppeur, plate-forme d'intgration, plate-forme de rfrence, environnement dexploitation). Les articles et leurs dpendances sont identifis dans la phase de prparation du projet. La phase de prparation permet de dcrire les diffrents environnements de ralisation. L'administrateur de la gestion de configuration dfinit l'ensemble des moyens de mmorisation (conservation temporaire, archivage) ncessaires la tche correspondante et attribue des droits d'accs aux personnes habilites. Il dfinit l'organisation des archives, en particulier leur taille et leur rpartition physique. Les espaces de dveloppement communiquent entre eux lors de l'intgration et de la validation des articles : c'est--dire lors de la phase de construction partir de la composition prcdente. Cette communication d'information se fait par l'octroi de visibilit certains espaces sur d'autres. Les espaces grs sont gnralement les suivants :

un espace de dveloppement par dveloppeur ; un espace d'intgration ; un espace de validation ; un espace de rfrence, qui contient tous les articles formellement valids par l'administrateur ; des espaces d'exploitation aprs dploiement.
La gestion des articles Un systme (livrable) est un regroupement d'articles divers : programmes, documents de conception et de spcification, procdures, jeux d'essais, etc. Le systme est dcompos de manire arborescente en sous-ensembles livrables qui runissent des composants de base (modules, composants de base ou fichiers). Il faut grer sparment :

la description du systme et de ses articles ; et le contenu des articles.

La description prcise la composition, l'identification et la rvision de chaque article et lui associent des informations sous forme d'attributs tels que : type, tat, description, date de cration, de modification etc. Les contenus des articles (programmes, textes, images etc.) sont rangs dans des archives qui contiennent les diverses rvisions, les modifications successives des sources, des binaires, des documents etc., protgs contre un accs non autoris. La description du systme peut inclure des articles externes dont le contenu n'est pas gr par l'outil. Il s'agit par exemple :

de documents qui ne sont pas sur support magntique ; de programmes externes (se trouvant sur d'autres plates-formes) ; de composants matriels.
Une base comprend la description des systmes grs et les archives associes. On considre un article commun plusieurs versions d'un systme ou, ventuellement, plusieurs systmes distincts, comme un lment unique.

La Lettre d'ADELI n44 Juillet 2001

21

La gestion des dpendances Les dpendances entre diffrents articles d'une configuration doivent tre connues et prises en compte pour dtecter les incohrences, et pour dterminer, tout moment, ce qui doit tre modifi pour rtablir un tat cohrent. La connaissance de ces dpendances permet de grer la cohrence des articles entre eux ; par exemple, un code source est dclar en incohrence ds que sa conception dtaille est modifie, une dition de liens est mise en incohrence ds que son fichier de directives est modifi ou dtruit. Ces dpendances serviront la gestion de production. La gestion des volutions Lorsqu'un systme volue, il faut :

partager

des composants entre diffrentes versions du mme logiciel, et entre diffrents logiciels ; les modifications sur la premire livraison doivent automatiquement tre rpercutes sur la livraison suivante, sachant que les deux configurations qui voluent, sont dveloppes, au mme moment, en parallle.

faire voluer une version pour crer une future livraison drive, partir d'une autre ; permettre des modifications en cascade sur des versions successives ; par exemple,

La gestion des modifications Lorsqu'un systme est livr un ou plusieurs utilisateurs, il faut respecter un processus de gestion des modifications, qui supporte le dialogue avec l'quipe de ralisation. Une modification a lune des origines suivantes :

rapport d'incident - description dune prsomption derreur dtecte l'utilisation ; demande d'volution - souhait d'volution fonctionnelle ou dadaptation technique ; en provenance de diverses sources : quipe de validation, client, utilisateurs etc.
Chaque demande est analyse, value (en fonction de ses impacts conomiques et organisationnels) avant de dcider de raliser ou de ne pas raliser la modification. La prise en compte de la modification transforme la demande initiale en fiches de modification relatives aux composants concerns. La fiche de modification dcrit les modifications effectuer ; elle est transmise l'quipe de dveloppement ou de maintenance qui extrait de l'archive les articles modifier et effectue les modifications demandes. Aprs validation, la nouvelle rvision cre est archive. Le dossier de suivi des modifications prcise de manire dtaille toutes les modifications effectues et dcrit la nouvelle rvision obtenue par diffrence avec la rvision prcdente. Il fait rfrence la fiche de modification qui a dclench les travaux.

22

La Lettre d'ADELI n44 Juillet 2001

Exemple de schma de principe du cycle de modification d'un article

Rapport dincident

Demande dvolution

Enregistrement Classification Acceptation

?
Analyse dimpact

Refus

Arbitrage

?
Acceptation Refus

Commande de modification Modification Vrification

Mise jour du systme

Dossier de suivi des modifications

Mise jour des configurations

La Lettre d'ADELI n44 Juillet 2001

23

La gestion de la production d'articles L'administrateur met en uvre tous les outils logistiques ncessaires pour :

automatiser les travaux rptitifs (par exemple, en enchanant la compilation et l'assemblage

de tous les modules du systme) ;

minimiser les manipulations (par exemple, en ne compilant que les modules rendus incohrents
par la modification d'un article source ou d'une spcification ) ;

tenir compte des dpendances entre les articles pour organiser la production (par exemple les
contraintes d'ordre entre modules compiler, assembler) ;

rsoudre grer

les problmes d'accs aux ressources (par exemple, les accs aux diffrentes bibliothques, les accs aux outils sous licence d'exploitation, les accs aux espaces d'archivage),

les compatibilits entre outils de production (par exemple, entre les versions de compilateur, de source). Tous les articles qui ont concouru la production d'un autre article doivent aussi tre grs en configuration. Pour permettre de relancer une production ultrieure, il faut savoir :

quelle version d'outil a t employe ? quand ? avec quelles options et quelles directives ?
La chane de dveloppement La chane croise permet d'excuter et de tester sur la plate-forme cible destine lexploitation alors que la chane native permet d'excuter et de tester sur une plate-forme de dveloppement distincte de la plate-forme dexploitation. Cependant, la chane native prsente des avantages sur la chane croise. Les dveloppements matriels et logiciels sont souvent parallles, la plate-forme cible qui hberge le logiciel n'est pas toujours disponible en temps voulu, en dure suffisante, pour satisfaire les besoins en ressources de l'quipement de test du logiciel. La gnration de rapports La gestion de configuration et de modifications des articles permet de constituer tous les rapports ncessaires au suivi. Les diffrents rapports d'audit et de suivi des dveloppements, doivent tre slectifs et rpondre aux normes de prsentation :

historique des modifications selon diffrents critres : qui fait quoi ? o ? quand ? comment ? journal d'activit ; rapport de diffrences entre deux versions ; etc. En pratique
Les mthodes et techniques de la gestion de configuration feront lobjet dun article complmentaire dans la LETTRE N45.

Alain Coulon Secrtaire dADELI

24

La Lettre d'ADELI n44 Juillet 2001