Annexe «gestion agile des projets informatiques. Guide de gestion des projets informatiques OFROU

(1)

Bundesamt für Strassen ASTRA Bruno Frey

Postadresse: 3003 Bern

Standortadresse: Mühlestrasse 2, 3063 Ittigen Tel. +41 31 323 34 76, Fax +41 31 325 01 64 [email protected]

www.astra.admin.ch

Mühlestrasse 2, 3063 Ittigen Standortadresse: Mühlestrasse 2, 3063 Ittigen Postadresse:

Annexe « gestion agile des projets informa- tiques »

Guide de gestion des projets informatiques OFROU

M233-1099

Informations

Date de création / date de révision : 22 août 2013

Auteurs : Membres permanents OFROU :

Bruno Frey (Frb), promoteur du projet Stoupa & Partners AG :

Daniela M. Schreier (Dms), Gwendolin Stoupa (Gs)

Nombre de pages : 20

Documents de référence : Guide de gestion des projets informatiques OFROU V1.03, 30.04.2012

Liste des modifications

Version Date Auteurs Remarques

(2)

2/20

1. Introduction... 4

1.1. Généralités ... 4

1.2. But de l’annexe ... 4

2. Structure de l'annexe ... 5

2.2. Référence au Guide de gestion des projets informatiques de l’OFROU ... 5

3. Définitions des termes ... 7

3.1. L’agilité au sein de l’OFROU ... 7

3.2. Document principal ... 7

3.3. Concepts du « cadre Scrum » ... 7

4. Directives ... 8

4.2. « Cadre Scrum » ... 8

4.3. Autres modèles et outils ... 8

4.3.1. Liste de contrôle « Décision relative à la réalisation agile de porjets » ... 8

5. Agilité dans le cadre des phases du projet ... 9

5.1. Phase du concept métier ... 9

5.2. Phase d'analyse préliminaire ... 9

5.3. Phases Conception IT et Réalisation ... 9

6. Organisation du projet et rôles ... 10

6.1. Organisation du projet ... 10

6.1.1. Vue externe de l'organisation de projets informatiques agiles de l'OFROU ... 11

6.1.2. Vue interne de l'organisation de projets informatiques agiles de l'OFROU (NOUVEAU) 12 6.2. Rôles importants dans un projet informatique agile (vue interne) ... 13

6.2.1. Rôles repris du guide de gestion des projets d'informatiques de l’OFROU ... 13

6.2.2. Rôles agiles conformément au concept « Scrum » ... 14

6.2.2.1. Equipe... 14

6.2.2.2. Scrum Master ... 14

6.2.2.3. Propriétaire du produit ... 15

6.2.3. Rôles complémentaires ... 16

6.2.3.1. Assistant du propriétaire du produit ... 16

6.2.3.2. Entraîneurs ... 17

6.2.3.3. Groupe d'utilisateurs ... 17

6.3. Affectation des rôles ... 18

7. Acquisition informatique et rédaction contractuelle dans le cadre de projets informatiques agiles de l'OFROU ... 19

8. Remarques et commentaires ... 20

8.1. Entité responsable de ce guide ... 20

8.2. Marquage des documents ... 20

8.3. Structure de stockage... 20

(3)

3/20

Sommaire des illustrations

Illustration 1 : Vue externe de l'organisation de projets informatiques agiles (voir document principal)11

Illustration 2 : Vue interne de l'organisation de projets informatiques agiles de l’OFROU ... 12

Illustration 3 : Rôles repris du document principal ... 13

Illustration 4 : Rôles agiles conformément au concept « Scrum » ... 14

Illustration 5 : Rôles complémentaires ... 16

Illustration 6 : Affectation des rôles ... 18

Sommaire des abréviations

AWG : rôle agile «Groupe d’utilisateurs» ... 17

CT : rôle agile «Coaches / Trainer» ... 17

GEVER/Fabasoft : logiciel standard pour le traitement électronique des processus et dossiers dans l’administration publique ... 8

HERMES : méthode de gestion de projets pour l’informatique, les prestations et les organisations commerciales, développé par l’administration fédérale ... 11

MISTRA : ... 20

OFROU : Office fédéral des routes ... 4

PO : rôle agile«Product Owner» conformément à Scrum ... 15

POS : rôle agile «Product Owner Supporter» ... 16

Rôle CoP «Comité de projet» conformément au guide de gestion des projets informatiques de l’OFROU ... 12

Rôle DO «Donneur d’ordres» conformément au guide de gestion des projets informatiques de l’OFROU ... 12

SM : rôle agile «Scrum Master» conformément à Scrum ... 14

T : rôle agile «Equipe» conformément à ... 14

(4)

4/20

1. Introduction

1.1. Généralités

L’agilité s'impose de plus en plus aussi bien dans le contexte informatique général qu'au sein de l'OFROU. Elle convient en premier lieu pour des projets informatiques complexes en raison de leur volume d'exigences techniques et / ou spécialisées ou présentant une forte composante inconnue (p.ex. nécessité de s'intégrer dans les vastes paysages informatiques existants ; pour les applica- tions ; etc.). La livraison régulière de résultats intermédiaires utilisables, la réévaluation et la définition des priorités pour les exigences ainsi que la compréhension des valeurs et actions prennent notamment en compte ces circonstances en cas de traitement agile d'un projet. Les erreurs de développe- ment sont ainsi souvent détectées tôt.

L'OFROU est dans l'ensemble bien structuré et offre un sol fertile pour la réalisation réussie de projets informatiques agiles.

1.2. But de l’annexe

Cette annexe doit mettre à disposition des directives et des expériences accumulées sur des projets informatiques agiles réalisés avec succès. Elle s'entend comme une « recommandation ». Elle com- plète le guide de gestion des projets informatiques OFROU.

Les descriptions se limitent aux aspects essentiels en prenant en compte une certaine harmonie avec la gestion traditionnelle de projets conformément au guide de gestion des projets informatiques OFROU. Cette annexe montre par ailleurs, les considérations pertinentes pour l'OFROU dans le cadre spécial des projets agiles d'un point de vue centralisé.

Cette annexe vise aussi à créer une compréhension homogène et une langue commune dans le cadre des projets informatiques agiles.

Le contenu de cette annexe n'est pas exhaustif et sera complété régulièrement. Cette annexe ne fournit pas de descriptions détaillées des processus agiles, cadres, comme p.ex. le Scrum, etc.

(5)

5/20

2. Structure de l'annexe

2.1. Généralités

Cette annexe décrit la compréhension du « vécu de l’agilité » dans le cadre de projets informatiques de l’OFROU.

2.2. Référence au Guide de gestion des projets informatiques de l’OFROU

Cette annexe complète les grands chapitres suivants du guide de gestion des projets informatiques de l’OFROU :

(6)

6/20



(7)

7/20

3. Définitions des termes

3.1. L’agilité au sein de l’OFROU

L’agilité est synonyme de mobilité. Un mode de travail mobile et pragmatique doit permettre d’obtenir des résultats présentant une valeur utile et une durabilité maximales pour l’OFROU tout en réduisant les dépenses au minimum.

Chaque projet informatique agile de l’OFROU doit posséder un objectif défini au préalable (vision du projet). Il convient de se rapprocher de cet objectif de manière itérative, axée sur les résultats et com- préhensible. Outre un mode de travail axé sur les objectifs et comprenant le moins de bureaucratie possible, il est notamment important que l’interaction soit excellente entre les collaborateurs du projet.

C’est en ce sens que nous parlons par la suite d’un « mode de travail agile ».

Les principes du Manifeste pour le développement agile de logiciels¹ fournissent les lignes directrices d’un mode de travail agile au sein de l’OFROU.

 Les individus et leurs interactions sont plus importants que les processus et les outils

 Des logiciels opérationnels sont plus importants qu’une documentation exhaustive

 La collaboration avec les clients est plus importante que la négociation contractuelle

 L’adaptation au changement est plus importante que le suivi d’un plan

3.2. Document principal

Le document principal désigne la version de base du guide de gestion des projets informatiques OFROU. En l'absence d'indication contraire, ce document se base sur les définitions des termes du document principal.

3.3. Concepts du « cadre Scrum »

Les concepts « Product Backlog », « Potentially Shippable Product (Product Increment) », « Sprint Backlog », « Sprint Goal », « Sprint Retrospective » et « Sprint Review » proviennent de la terminolo- gie du « cadre Scrum » et peuvent être p.ex. consultés dans le « Scrum Guide »².

1 http://agilemanifesto.org/iso/fr/

2 « The Scrum Guide », octobre 2011, conçu et tenu à jour par Ken Schwaber et Jeff Sutherland

(8)

8/20

4. Directives

4.1. Généralités

Dans le cadre du traitement à fins d’actualisation du guide de gestion des programmes informatiques de l’OFROU avec ajout des aspects agiles, il s’est avéré que certaines directives contraignantes dans le cadre de la réalisation des projets informatiques agiles de l’OFROU étaient judicieuses. Plusieurs raisons le justifient entre autres :

 Etablissement d’une certaine cohérence dans le mode de travail avec obtention de l’efficacité lors du travail et échange et développement de connaissances au sein de l’OFROU ;

 Création d’une base pour un contrôle sur l’ensemble du projet ;

 Communication efficiente par le recours à une langue commune ;

 etc.

4.2. « Cadre Scrum »

La base des projets informatiques agiles de l’OFROU est le « cadre Scrum »³. Cela vaut notamment pour l’occupation des rôles et l’utilisation des principaux artefacts. D’autres outils, processus, mé- thodes agiles, etc. peuvent être utilisés en complément ou en élargissement.

4.3. Autres modèles et outils

4.3.1. Liste de contrôle « Décision relative à la réalisation agile de projets »

Cette liste de contrôle aide à décider si un projet informatique doit être réalisé de manière agile ou non.

La liste de contrôle est enregistrée en allemand et en français sur GEVER/Fabasoft :

 version allemande : M344-0029

 version française : M344-0030

3 « The Scrum Guide », octobre 2011, conçu et tenu à jour par Ken Schwaber et Jeff Sutherland

(9)

9/20

5. Agilité dans le cadre des phases du projet

5.1. Phase du concept métier

Une proposition est que le concept métier doit déjà être démarré de manière agile avec un chef de projet métier et, si besoin est, un chef de projet informatique afin d'exploiter les valeurs d'expérience et les avis de différents domaines spécialisés et techniques et de pouvoir contrer d'éventuels dévelop- pements erronés.

5.2. Phase d'analyse préliminaire

La phase d'analyse préliminaire permet de définir une recommandation en faveur d'une approche agile ou contre cette approche. Les résultats de l'examen des objectifs du projet et des bases de dé- termination du type de projet permettent toujours une telle recommandation. Les rôles et documenta- tions nécessaires doivent être déterminés à l'aide du type de projet défini. Il convient par ailleurs de définir les processus, les méthodes, les cadres, etc. agiles à utiliser et pourquoi. Cette recommandation influe sur la planification de l'organisation du projet effectuée pendant cette phase. La décision de réaliser ou d'acheter (Make-or-Buy) est aussi prise pendant cette phase.

La recommandation doit par conséquent aussi être prise en compte dans le cadre de l’acquisition informatique et de la rédaction contractuelle informatique.

5.3. Phases Conception IT et Réalisation

La conception informatique définit les conditions cadres de la réalisation informatique technique. La décision d'opter ou non pour une approche agile pour le projet est prise au plus tard lors de la phase de réalisation car c'est aussi là que sont entre autres élaborés les documents d'acquisition.

(10)

10/20

6. Organisation du projet et rôles

Un projet informatique se définit par son unicité et sa durée limitée. Il nécessite une organisation parti- culière, qui, dans la plupart des cas, ne correspond pas à l'organisation hiérarchique. Des rôles spéci- fiques n'existant pas dans l'organisation traditionnelle de projets (conformément au document principal) doivent être pris en compte dans le cadre de projets informatiques agiles.

L'organisation des projets informatiques agiles de l’OFROU est présentée dans ce chapitre qui ex- plique et montre les vues de l'organisation du projet et les rôles principaux.

On a par ailleurs une recommandation pour l’occupation des rôles agiles.

6.1. Organisation du projet

L'organisation du projet est définie pour une durée fixe. Elle se superpose à l'organisation traditionnelle du projet d'une part, et d'autre part doit être clairement ancrée dans celle-ci. L'organisation du projet présentée dans cette annexe est générique et doit être modifiée en fonction de la situation du projet informatique agile.

Dans le cadre de projets informatiques agiles, on fait la distinction entre deux vues de l'organisation du projet :

 la vue externe pour les projets informatiques généraux de l’OFROU (conformément au document principal) et la

 vue interne qui prend en compte les besoins spéciaux dans le cadre d'un traitement agile du projet.

(11)

11/20

Dans un projet informatique agile de l’OFROU, la forme de l’organisation du projet vers l’extérieur doit être conservée dans le guide de gestion des projets informatiques de l’OFROU / HERMES conformé- ment au guide de gestion des projets informatiques. Il faut p.ex. toujours comme avant un système de rapports correspondant. C’est la raison pour laquelle l’illustration suivante qui décrit cette vue externe a été reprise sans changement du document principal et est encore mentionnée ici. Les détails figu- rent dans le document principal.

Illustration 1 : Vue externe de l'organisation de projets informatiques agiles (voir document principal)

(12)

12/20

La vue interne sur l’organisation du projet couvre les besoins dans le cadre d'une réalisation agile de projets informatiques. Elle concerne en premier lieu les personnes participant activement à la réalisa- tion du projet informatique agile.

Dans le contexte de la vue interne, on vise principalement à ce que tous les participants (dans le cadre des rôles qui leur sont affectés) assument au mieux leur responsabilité et puissent parfaitement assumer leurs tâches. Par conséquent, chacun est habilité à s’imposer en prenant en compte le manifeste⁴ agile et en s’axant sur l’objectif et la solution. On doit volontairement s’écarter d’une réflexion hiérarchique « classique ».

Les rôles « CoP » et « DO » doivent être interprétés conformément à la vue externe et au document principal.

Illustration 2 : Vue interne de l'organisation de projets informatiques agiles de l’OFROU

4 http://agilemanifesto.org/iso/fr/

(13)

13/20

6.2. Rôles importants dans un projet informatique agile (vue in- terne)

Les rôles représentent toujours des profils définis dans le cadre de projets informatiques agiles de l’OFROU. Ils sont nécessaires pour la gestion des tâches, la communication, la suppression des ma- lentendus en rapport avec les responsabilités, les tâches (fondamentales) et les compétences.

La suite du présent document énumère et décrit les nouveaux rôles venant s'ajouter dans le cadre de projets informatiques agiles de l’OFROU afin de créer une compréhension commune dans un contexte agile. Les responsabilités, tâches et aptitudes nécessaires sont décrites au minimum et doivent donc être reprises telles quelles et développées en fonction de la situation. Pour réussir un projet informatique agile, il est important de définir clairement ces rôles avec la compréhension culturelle né- cessaire au début d'un projet informatique et d'affecter les différentes personnes concrètes aux diffé- rents rôles.

Comme le montre l'illustration 2, les rôles peuvent être divisés en trois catégories :

 Rôles repris du document principal,

 Rôles agiles conformément à Scrum et

 Rôles complémentaires

Les différents rôles vont maintenant être décrits concrètement dans leur forme générique.

6.2.1. Rôles repris du guide de gestion des projets d'informatiques de l’OFROU

Les rôles suivants ont été repris du document principal :

 Comité de projet et

 Donneur d'ordre.

Illustration 3 : Rôles repris du document principal

Ces deux rôles doivent aussi être utilisés judicieusement dans le cadre de projets informatiques agiles de l’OFROU. Ils sont repris dans le contexte agile conformément à leur description dans le document principal.

(14)

14/20

Les rôles suivants sont repris du « cadre Scrum » :

 Equipe,

 « Scrum Master » et

 Propriétaire du produit.

Illustration 4 : Rôles agiles conformément au concept « Scrum »

Les descriptions suivantes doivent montrer les aspects importants pour l'OFROU.

6.2.2.1. Equipe

Nom Equipe (T pour « Team ») 3 à 9 personnes

Domaine de responsabilité

L'équipe est responsable de la mise en œuvre des prestations promises au cours de la prochaine période de travail (sprint). Dans l'idéal, elle est composée de personnes de différentes spécialités (p.ex. analyse, conception, programmation, test, etc.).

Tâches et compétences

L’équipe

 définit l'objectif du sprint (Sprint Goal) ;

 rend visibles les contenus et progrès de son travail ;

 présente le produit potentiellement livrable (« Potentially Shippable Product ») lors de l'examen du sprint ;

 s'organise elle-même ;

 est très motivée et met tout en œuvre pour atteindre l'objectif du sprint ;

 agit avec une conscience extrême de ses responsabilités ;

 peut s'adapter avec flexibilité aux nouvelles situations ;

 a la volonté de s'améliorer en permanence (rétrospective du sprint).

6.2.2.2. Scrum Master

Nom Scrum Master (SM) une personne

Le Scrum Master est responsable du respect du processus.

Le Scrum Master :

 guide les acteurs lors du processus en servant ;

 n'exerce pas d'autorité ;

 élimine les obstacles et veille à ce que l'équipe fonctionne / puisse travailler de manière productive ;

 assure un excellent environnement de travail à l'équipe ;

(15)

15/20

 anime p.ex. les réunions de mêlée ;

 nécessite une compétence de direction élevée ;

 remarque les problèmes / conflits et trouve les déclencheurs ;

 résout les problèmes et dirige les négociations ; décèle les dépendances, ce qui pourrait poser problème, les points critiques & les « goulots » ;

 a une attitude ouverte vis-à-vis de la critique et des remarques ;

 collabore ;

 favorise la conscience commune des responsabilités pour le succès global du projet informatique ;

 sait pousser les gens et les encourager.

6.2.2.3. Propriétaire du produit

Nom Propriétaire du produit (PO pour « Product Owner ») une personne

Domaine de res- ponsabilité

Le propriétaire du produit est responsable de la durabilité et de la valeur de la solution pour l’OFROU ainsi que du carnet du produit (Product Backlog). Il dé- cide des exigences à mettre en œuvre en conséquence et est par ailleurs responsable du budget du projet informatique.

Dans le domaine de responsabilité, on n'a qu'un propriétaire par projet informatique. Il peut être assisté par l'assistant du propriétaire du produit (« Product Owner Supporter » ou POS).

Tâches et com- pétences

Le propriétaire du produit.

 détermine en fin de compte la vision du projet informatique et la commu- nique clairement et de manière compréhensible aux parties prenantes du projet (notamment à l'équipe) ;

 formule et détermine le contenu (scénarios des utilisateurs / fonctionnalités) de la solution ;

 définit les priorités (Product Backlog) ;

 vérifie le contenu et les priorités de chaque sprint (valeur, durabilité, quali- té) ;

 veille à ce que le contenu du carnet du produit soit correctement compris ;

 représente le « véritable client » ;

 réceptionne le travail de l'équipe ou le renvoie (examen du sprint) ;

 décide quand un résultat terminé (Release) doit être publié ;

 possède un excellent savoir-faire métier et a une vaste compréhension technique (ou est aidé par un POS disposant du savoir-faire correspondant) afin de pouvoir prendre des décisions ciblées et cohérentes ;

 ne perd jamais de vue la durabilité et la valeur de la solution pour l’OFROU ;

 est capable de s'imposer ;

 sait s'exprimer clairement.

Remarques par- ticulières

 Un collaborateur embauché par l'OFROU est favorisé pour ce rôle afin que les intérêts de l'OFROU soient représentés au mieux.

 Le PO doit par ailleurs avoir suffisamment de capacités pour s'acquitter de ses tâches et disposer du pouvoir de décision nécessaire ce qui est considé- ré comme un facteur déterminant pour le succès d’un projet informatique agile de l’OFROU.

(16)

16/20

Les rôles suivants doivent être occupés / considérés de manière spécifique à l'OFROU dans le cadre de projets informatiques agiles :

 Assistant du propriétaire du produit (Product Owner Supporter),

 Entraîneurs (Coaches / Trainers) et

 Groupe d'utilisateurs

Illustration 5 : Rôles complémentaires

6.2.3.1. Assistant du propriétaire du produit

Nom Assistant du propriétaire du produit (POS pour

« Product Owner Supporter ») Plusieurs personnes

Les assistants des propriétaires des produits doivent assister au mieux le proprié- taire du produit et le cas échéant compenser les compétences qui manquent au propriétaire du produit.

Un assistant du propriétaire du produit :

 assiste le propriétaire du produit dans ses tâches

Remarques particulières

 Il s'agit d'un groupe de personnes pouvant provenir de différentes disciplines.

(17)

17/20

Nom Entraîneurs (CT pour « Coach / Trainer »)

Plusieurs personnes

Un entraîneur est un mentor pour tous les collaborateurs de l'OFROU participant à des projets informatiques agiles. Il doit veiller à rendre possibles les actions agiles et à ce qu'elles soient comprises par tous les participants.

Un entraîneur (Coach) :

 assiste notamment le Scrum Master, le propriétaire du produit et l'équipe mais aussi les autres participants au projet dans le cadre de la mise en œuvre du projet agile ;

 peut encadrer plusieurs projets informatiques de l’OFROU ;

 aide à harmoniser les méthodes agiles avec d'autres méthodes (comme HERMES) ;

 collecte les expériences de projets dans le cadre d'une approche structurée et périodique et les consigne par écrit ;

 possède un solide savoir-faire dans le domaine de l’agilité ;

 apporte en général un solide savoir-faire informatique :

 a accumulé de solides expériences lors de projets agiles en tant que Scrum Master ou de propriétaire du produit ;

 possède les capacités d'un Scrum Master et une compétence élevée en rela- tions humaines ;

 est en mesure d'accompagner le processus de changement ;

 ne prend pas parti.

6.2.3.3. Groupe d'utilisateurs

Nom Groupe d'utilisateurs (AWG pour « Anwender-

gruppe ») Plusieurs personnes

Le groupe d'utilisateurs est constitué des personnes utilisant en fin de compte la solution. Ce sont elles qui doivent informer au mieux sur l'intérêt de la solution informatique.

Le groupe d'utilisateurs :

 fournit les exigences à l'égard du projet informatique ;

 teste et évalue la solution et les résultats intermédiaires fournis ;

 doit être axé sur la solution, constructif et proactif.

(18)

18/20

6.3. Affectation des rôles

Le tableau suivant montre les rôles du guide de gestion des projets informatiques OFROU pouvant affectés aux rôles dans le cadre d'un projet informatique agile.

La colonne de gauche « Rôles conformément au guide de gestion des projets informatiques OFROU » contient la liste des rôles importants dans un projet informatique conformément au document principal. La partie de droite « Rôles dans des projets informatiques agiles » montre les rôles à occuper dans des projets informatiques agiles de l’OFROU. Les rôles « DO » et « CoP » doivent être repris conformément à la définition de l'organisation traditionnelle du projet (voir document principal).

Si plusieurs rôles agiles sont affectés à un rôle du guide, cela signifie que la personne peut assumer l'un « ou » l'autre rôle.

Illustration 6 : Affectation des rôles

(19)

19/20

7. Acquisition informatique et rédaction contrac- tuelle dans le cadre de projets informatiques agiles de l'OFROU

Afin de créer une sécurité juridique accrue et de centraliser les connaissances et les mettre à la disposition de tous les collaborateurs de l'OFROU, le thème de l'acquisition informatique et de la rédac- tion contractuelle dans le cadre de projets informatiques agiles de l’OFROU est actuellement en cours d'actualisation.

(20)

20/20

8. Remarques et commentaires

8.1. Entité responsable de ce guide

Le secteur Controlling-IT / Gestion des projets-IT de l'OFROU est l'entité responsable pour le respect et l'administration de la gestion des projets informatiques et par conséquent du présent guide : Office fédéral des routes

Informatique stratégique

Controlling-IT et Gestion des projets-IT Bruno Frey

Pulverstrasse 11

3063 Ittigen, adresse postale : 3003 Berne

Courriel : [email protected] Site Internet : www.it-pm-astra.ch Téléphone : +41 31 323 34 76 Fax : +41 31 325 01 64

Le présent guide est contraignant pour les projets informatiques au sein de l'OFROU. Toute déroga- tion doit être clarifiée et coordonnée avec le secteur Controlling-IT / Gestion des projets-IT.

8.2. Marquage des documents

Il n'existe aucune exigence ni directive OFROU en matière de marquage des documents. Le choix du type de marquage est donc entièrement de la responsabilité du chef de projet et doit être réglementé dans le manuel de projet. Deux options possibles de marquage des documents :

sigle du projet_date_type de doc_nom du document_<L>_versionxx.yy Exemple : KUBA_20111025_PH_Pflichtenheft-KUBA6_d_V01.00

type de document_sigle du projet_nom du document_L_date_versionxx.yy Exemple : PH_KUBA_Pflichtenheft-KUBA6_d_20111025_V01.00

Décomposition :

Date : date d'édition (aaaammjj = année/mois/jour)

Versionxx.yy : version de l'édition, la version d'une ébauche porte l'initiale X et une version approuvée porte l'initiale V

L : langue (d, f, i, e)

Type de doc : BE = rapport, PR = présentation, AK = note d'accompagnement, AU = document de travail, BF = lettre, HB = manuel, PH = cahier des charges, PK = pro- cès-verbal, ZE = dessin

Des informations et conseils supplémentaires relatifs au marquage des documents peuvent être obte- nus auprès du secteur Controlling-IT / Gestion des projets IT de l'OFROU.

8.3. Structure de stockage

OFROU ne dispose pas encore d'exigences et de directives relatives au stockage des documents.

Des informations et conseils supplémentaires relatifs au stockage des documents peuvent être obte- nus auprès du secteur Controlling-IT / Gestion des projets IT de l'OFROU. Le manuel de projet MISTRA peut être utilisé en guise d'exemple.