Demarche Projet Production

Démarche d’un projet Informatique (prod/system)
Démarche projet informatique

(PROD/EXPLOIT SYSTEME)
61 rue Henri Barbusse 92110 CLICHY Tél. : +33 183 64 67 60 Fax : +33 155 48 09 18 [email protected]
Sommaire
Table des matières

1. Introduction ........................................................................................................................................ 4
2. Les services qui participent à un projet informatique .......................................................................... 5
a. La Maîtrise d’Ouvrage (MOA):……………………………………………………………………...5
Le Chef de Projet Maîtrise d’Ouvrage (CPMOA)............................................................................... 5
Les experts métier ............................................................................................................................... 5
Les assistants maîtrise d’ouvrage ........................................................................................................ 5
b. La Direction des Systèmes d’Information (DSI) ................................................................................ 5
Service Etudes .................................................................................................................................... 5
Service Système .................................................................................................................................. 5
c. Le Service de Production et d‘Exploitation 6
d. Le Service Micros et Réseaux 6
3. Les étapes d’un projet informatique :.................................................................................................. 6
a. Mise en production…………………………………………………………………………………..7
b. Le déploiement………………………………………………………………………………………7
c. Le chronogramme :…………………………….…………………………………………………….7
d. Versionage…………………………………….……………………………………………………..7
4. Les ressources du service PROD/SYSTEME: ................................................................................... 8
a. Les DBA :…………………………………………………………………………………………....8
b. L’Administrateur Système :………………………………………..……………………………….11
c. L’Administrateur Réseau :………………………………………………………………………….12
d. L’ingénieur de production exploitation :…………………………………………………………...14
Annexe…………………………………………………………………………………………………16
AnnexeI1 : Plannification……………………………………………………………………………...16
Annexe II : Les réunions……………………………………………………………………………....16
a. Diagramme de GANTT (planning à barres)………………………………………………………..16
b. Planning Prévisionnel………………………………………………………………………………16
Périmètre de la réunion .................................................................................................................... 18
Organisation générale....................................................................................................................... 18
Le compte rendu ............................................................................................................................... 19
Types de réunions ............................................................................................................................ 19
Annexe III :………….……………………………………………………………………………...…22
a. Le modèle entité-association (Le model conceptuel de données) .................................................... 20
b. Passage du MCD au MPD………………………………………………………………………….20
1. Les types de programmes ................................................................................................................. 23
Annexe IV : Définition………………………………………………………………………………...25
a. Les programmes transactionnels TP………………………………………………………………..23
b. Les Batchs………………………………………………………………………………………….23
c. Les états…………………………………………………………………………………………….27
2. Anomalie (ano)................................................................................................................................. 27
3. Evolution (évo)................................................................................................................................. 28
4. Avenant ............................................................................................................................................ 28
5. Environnements de travail ................................................................................................................ 28
6. Lotissement ...................................................................................................................................... 29
2
7. Support utilisateur ............................................................................................................................ 29

8. Interlocuteurs et tâches des assistants MOA et MOE ...................................................................... 30
3
1. Introduction
La production exploitation est un service critique qui sera plus détaillés dans ce document.
La prestation de service informatique est l’ensemble des tâches sous-traitées par une entreprise cliente
à une ou plusieurs entreprises de services informatiques. Elle a deux particularités :
Les projets informatiques durent longtemps (charge de travail en année/homme) et coûtent cher ce qui
pousse le client à prendre plusieurs fournisseurs. Le client, le plus souvent, n’est pas informaticien.
 La culture PROD/SYSTEME (historique) :

La culture du service de production et du système est une culture bâtis sur des ressources qui n’était
pas informaticien depuis les années 70, des ressources qui maitrisent l’utilisation d’outils de production
et de système afin de ne pas s’ingérer dans les données réelles, pour des soucis de sécurité
A partir de ce moment les gens (ressources) qui constituent ces services en ce temps-là n’avaient pas
besoin d’un niveau bac + 15 et cela pour des raisons économique (rémunération, cout) ; « on n’allait
pas ramener Messie pour le FC Clichy». Par contre coté client, c’est les gens qui conçoivent,
développent et mettent en place ces programmes, sont de niveau ingénieurs et ceux qui donnent
l’ordre ou les clients de ceux qui conçoivent les programmes sont des gens de grandes écoles mais ça
ce fut dans les années 70. Maintenant tout évolue, même chez Mc Donald’s on trouve des ressources
Bac + 5 car y a une crise mondiale, chômage … les services d’études, réseaux et production ont
évolué aussi, le point important pour les clients de ces ressources est la rigueur car ils doivent
respecter des jalons et dates butoirs.
Comme pour le passage à l’euro en 2002 toutes les banques devaient passer à l’euro le 31 décembre
2001 c’est une date butoir, aucune banque ne pouvait se permettre de ne pas mettre à jour ou à
niveau son SI (système d’Information) car cela aurait était catastrophique pour la banque qui pouvait
même déposer le bilan. Aussi comme exemple une loi qui doit passer à une date précise une loi de
finance ou assurance ou qui impacte tout autre secteur on a une date butoir ou les banque et
assurances doivent intégrer ces nouvelles lois sinon les conséquences seraient énormes voir
irrémédiables.
Dans ce sens donc ces clients ont besoin de ressources qui ont fait des études et qui ont l’habitude de
géré des dates butoirs avec toutes la complexité qui va avec.
Autre exemple : à ISSMI si vous ne rendez pas vos livrables à la date prévue (date butoir), vous aurais
un zéro (voir pire encore votre formation peut prendre fin), non pas par méchanceté c’est compliqué
et complexe probablement (au début) mais c’est pour vous préparer justement à un contexte
professionnel.
La clé de la réussite pourquoi je vous parle de tout ça ce n’est point pour une discussion de salon
mais le cœur de la discussion c’est de vous permettre de vous intégrer la vie professionnelle, une fois
qu’on a compris que les conflits humains sont susceptibles de gâché une intégration professionnelle, le
lancement votre carrière est réussie.
Dans ce domaine (PROD/SYSTEM) les ressources sont issu de plusieurs cursus hors informatique mais
paradoxalement les mieux payé
Les clients de la PROD/SYSTEM sont des gens sous tension, il faut être calme et réactif (calmer son
interlocuteur et être réactif) « motivation, Prestige et Efficacité »
Il faut s’engager sur un délai suivant la visibilité sur le besoin ou l’incident (dans la majorité des cas)
4
c’est une information critique.

En résumé il ne faut pas prendre les remarques du client comme attaque personnel car ça reste un
contexte professionnel.
2. Les services qui participent à un projet informatique

La Maîtrise d’Ouvrage (MOA):
La MOA est l’ensemble des équipes de maîtrise d’ouvrage. Elle peut être centralisée (une équipe
pour un ensemble de projets) ou décentralisée (chaque projet a son équipe). L’ensemble de son
effectif peut aller de 15 à 250 personnes alors que l’effectif d’une équipe de maîtrise d’ouvrage qui
est généralement le tiers de l’effectif d’une équipe de maîtrise d’œuvre peut aller de 0,5 (correspond
la moitié du temps de travail d’une personne, ressource transverse) à 5 personnes.
La MOA est composée de trois types de ressources humaines :
 Le Chef de Projet Maîtrise d’Ouvrage (CPMOA)
Sa tâche est gérée le projet et les plannings. Et qui est l’un des interlocuteurs de la PROD/SYSTEME
(client du service PROD/SYSTEME) c’est le gestionnaire du budget mais en aucun cas le supérieur
hiérarchique de la ressource de PROD/SYSTEME.
 Les experts métier
L’expert métier est une personne qui maîtrise la démarche métier à ne pas confondre avec l’utilisateur
final. Il fait forcement parti de l’entreprise cliente. Exemples : pour une application de comptabilité,
l’expert métier doit être un comptable voire le meilleur des comptables de l’entreprise, pour une
application d’électricité ça sera un électricien, application bancaire un banquier …
Son travail est de répondre à toutes les questions des assistants MOA afin de fournir la solution la plus
adapté au besoin du client (l’entreprise).
 Les assistants maîtrise d’ouvrage
L’assistant maîtrise d’ouvrage doit comprendre les exigences de l’expert métier et les transmettre à
l’équipe de développement. Il a les deux démarches, métier et projet.
La Direction des Systèmes d’Information (DSI)
La DSI est toujours centralisée. Elle est composée de deux sous services :
 Service Etudes
C’est l’ensemble des équipes de maîtrise d’œuvre (équipes MOE) ou
développement Composition d’une équipe Etudes :
 Cas d’un projet d’envergure (appelée équipe MOE) :
 Le Chef de Projet de Maîtrise d’Œuvre qui est l’un des interlocuteurs de la PROD/SYSTEME
 L’Assistant Maîtrise d’œuvre : Chargé de l’analyse
 Ingénieurs d’études et développement : Chargés du développement
 Cas d’un petit projet ou projet de maintenance (appelée équipe de développement) :
 Chef de projet de développement
 Ingénieurs d’études et développement
Le service Etudes représente le plus gros des effectifs d’un projet, entre 45 et 1200 personnes.
L’effectif d’une équipe d’Etudes et développement varie entre 3 et 15 personnes.
 Service Système
5
Composé de l’ensemble des équipes système. L’effectif du service système est comparable à celui du
service MOA. Une équipe système est composée de :
 Ingénieur système et réseaux : Administre les serveurs
 Administrateur de bases de données : responsable de la structure de la base.
Le service système est un service transverse sur plusieurs projets. Ce sont des ressources humaines
critiques.
Le Service de Production et d‘Exploitation
A ce niveau les applications sont opérationnelles avec des données réelles.

Il est comparable au service système au niveau effectif et travail. Il veille sur le bon
fonctionnement du serveur de l’application. Sa mission est principalement préventive. Une équipe
de production et d’exploitation est composée de :
 Ingénieur système et réseau
 Administrateur de bases de données
 Exploitants
Le Service Micros et Réseaux

Concerne tout le parc informatique de la société. Ses tâches sont la maintenance des ordinateurs,
l’installation des logiciels et le déploiement des applications. Son effectif varie entre 5 et 200
personnes selon qu’il y ait déploiement ou pas.
3. Les étapes d’un projet informatique :

Comme stipulé au début de ce document qu’il est destiné spécialement ressources système les
étapes d’un projet ne seront pas détaillés.
Un projet informatique commence par l’expression du besoin, suivit par une phase de
documentation les assistants maitrise d’ouvrage (MOA) vont rédiger les spécifications générales
détaillés (SFG) sur la base des comptes rendu des interviews avec l’expert métier. Par la suite, les
assistants maitrise d’œuvre (MOE) vont rédiger les spécifications fonctionnelles détaillées (SFD) à
partir des SFG en cas d’ambiguïtés des réunions seront misent en place avec les AMOA afin de les
levées. Une fois validée, les SFD seront les supports pour la réalisation des documents techniques
(Analyse Organique, MCD, MCT …) et on passe aux développements.
L’application développée va passer par l’ensemble des environnements pour la deuxième phase du
projet à savoir les tests avant d’être Mise en PROD (MEP), en environnement de développement c’est
les tests unitaires effectué par les développeurs, dans l’environnement d’intégration c’est les tests
d’intégration fait par la MOE et enfin la recette dans l’environnement de recette par la MOA qui se
soldent par un PV de recette qui est le Go ou non Go pour la mise en production.
6
Mise en production
Cette étape consiste à mettre l’application sur le serveur de production et la tester sur un site pilote
ou un poste pilote si le nombre d’utilisateur de l’application est restreint.
La veille de la mise en production les batchs d’alimentation de la base de données sont lancées. Le
jour de la mise en production il faut se présenter très tôt afin d’analyser les logs générés par les batchs
d’alimentation et résoudre les éventuels rejets avant l’ouverture des TP. Si les rejets sont dus à des
batchs critiques, il faut absolument les corriger et relancer les batchs dans la journée en fermant les
TP. S’ils sont dus à des batchs non critiques on les relance une autre nuit.
NB : à ne pas confondre avec le déploiement qui consiste à mettre l’application sur tous les postes utilisateurs de
façon à être accessible aux clients.
Le déploiement
Consiste à rendre l’application accessible à tous les utilisateurs finaux. C’est le service micro et
réseaux qui s‘en charge.
Le chronogramme :
C’est un outil qui permet l’ordonnancement des batchs, scripts ou encore application … à
exécuter pour qu’ils puissent tous passer suivant les besoins (planification des exécutions). Le
service études se charge de demander au service exploitation et production de réaliser le
chronogramme via des outils spécialisés comme control-m, Dollar Universe, V-TOM, OPALIS...
L’ordonnanceur ou chronogramme a une double utilité (en PROD) d’une part minimiser
l’intervention humaine en automatisant le lancement des traitements et aussi ça permet de
centraliser le suivi de PROD d’où une réactivité maximale pour le traitement des incidents et un
MCO (Maintien en Conditions Opérationnelles) optimal.
Versionage
Fait par l’intégrateur avec des outils de Versionage tel Visual Source Safe et Clear Case ou
encore des outils développés en interne.
L’application est composée d’une partie traitement et d’une partie donnée. Chacune des
parties à son numéro de version qui évolue indépendamment de l’autre partie sans oublier la
documentation, en fonction des anomalies et des évolutions. On doit avoir une correspondance
entre les versions des deux parties qui fonctionnent ensemble.
En cas d’anomalie ou d’évolution que ce soit dans le système de données ou de traitement, le
développeur indique à l’intégrateur la correspondance entre les anomalies ou les évolutions et les
programmes ou scripts qui les traitent.
Pour chaque environnement l’intégrateur doit avoir le tableau de
correspondance. Exemple de tableau de correspondance :
7
Version du Contenu Contenu technique Contenu technique

Version de la BD
traitement fonctionnel de la BD de traitement
1.0.0 1.0.0 Spec de 1 à 30 Script de 1 à 200 Prog de 1 à 200

1.0.0 1.0.1 Ano 1 Script 22 bis
1.1.0 1.0.1 Evo 1 Prog 201
….. ….. ….. ….. …..
….. ….. ….. ….. Script …..
7.2.3 5.3.2 Ano 25, Evo 34 106 Prog
219
4. Les ressources du service PROD/SYSTEME :

Les DBA :
L'administrateur de base de données (DBA : DataBase Administrator en anglais) est une
personne responsable du bon fonctionnement de serveurs de bases de données, essentiellement
relationnelles ou décisionnelles, tant au niveau de la conception des bases, des tests de validation,
de la coordination des intervenants, de l'exploitation, de la protection et du contrôle d'utilisation.
Au niveau d’un projet informatique on distingue deux profiles :
Les taches et compétences des deux profils sont pratiquement les mêmes
- DBA études qui est orienté conception : Il travaille conjointement avec les équipes de
développement et est responsable du modèle logique et physique de la base de données. Il a
souvent à charge l'administration des bases pendant la durée du projet. Il peut être amené à
développer les procédures ou scripts SQL, et participe à la validation et aux tests. Il est très
souvent responsable du contenu et du contenant (les données et le serveur lui-même).
- DBA PROD qui est orienté prévention : Il assure la disponibilité et le bon fonctionnement des
systèmes de bases de données. Il travaille en environnement haute disponibilité 24h/24h 7/7j. Cette
fonction s'accompagne presque systématiquement d'astreintes. La volumétrie peut ici être très
importante, quelques dizaines à quelques milliers de bases de données par DBA, soit au maximum
une centaine de serveurs à surveiller. Il est en général responsable du contenant mais pas du
contenu : le système de bases de données, mais pas les données elles-mêmes. Cependant il doit
toujours être en mesure de récupérer les données, et de restaurer une image valide des systèmes. Il
est mieux rémunéré que l'administrateur développement principalement à cause des risques et des
responsabilités qu'il assume : une panne majeure pouvant aller jusqu'à la faillite de la compagnie.
 Taches principales :
8
Il peut assurer tout ou une partie de ces taches :
Le rôle de l'administrateur de bases de données est d’organiser et de gérer en toute fiabilité les
systèmes de gestion des données de l'entreprise. Il doit en assurer la cohérence, la qualité et la sécurité.
Il peut avoir à gérer plusieurs bases de données.
Il participe au choix des progiciels et à la mise en œuvre des bases de données de l'entreprise. C’est
ensuite lui qui installe, configure, administre et optimise les bases. Au-delà de l’aspect technique, il
prend en compte tout l’environnement de l’entreprise ainsi que les besoins et les requêtes des
utilisateurs.
Il est au carrefour de différents services avec lesquels il travaille. Il peut participer à la formation
des utilisateurs dans l’entreprise. Il peut être amené à faire des déplacements dans ou hors de
l’entreprise ou intervenir sur la base en dehors des heures ouvrables.
 La mise en place de standards, préconisation et bonnes pratiques :

Il décide des normes de nommage des objets pour les bases créées en interne, édicte les bonnes
pratiques que les développeurs devront suivre, documente les procédures de maintenance afin que
d'autres acteurs puissent intervenir en son absence.
 L'évaluation des besoins et de la qualité :

Certaines bases de données n'étant pas développées de manière interne, il est important qu'il soit
consulté afin de dimensionner les serveurs devant héberger une solution applicative d'éditeur, tant sur
le plan des ressources (volumétrie, nombre d'accès), que sur le plan de la maintenance (maintien des
performances, fréquence des sauvegardes…).
 La modélisation de la base :
Bien qu'elle incombe normalement à l'analyste ou au concepteur (parfois au développeur), les
principes de modélisation de bases de données doivent être parfaitement maitrisés par le DBA. En
effet, les facteurs de dégradation des performances étant en premier lieu liés à la structuration des
données (respects des principes de modélisation, relationnel ou décisionnel…), le DBA se doit de bien
connaître les principes de modélisation et les problématiques en jeu afin de conseiller les analystes et
développeurs ou bien pour résoudre les problèmes de performance à ce niveau par refactoring.
 La définition et la gestion des espaces de stockage :

Comme une base de données a besoin de beaucoup de place pour les données et le journal de
transaction, il doit dimensionner les espaces de stockage physiques (stockage : tables pace, groupes
de fichiers…) et logiques (partitionnement), et choisir les disques ou SAN de manière préventive, et
les auditer régulièrement afin de décider de l'ajout ou du basculement de certains objets logiques sur
de nouveaux espaces (croissance de la volumétrie des données et "capacity planning").
9
 L'intégrité des données :

Il vérifie ou aide à vérifier la cohérence des données de la base afin qu'elles ne rentrent pas en
conflit avec les principes du système réel. Pour cela, il est chargé de la mise en œuvre de contraintes
d'intégrité (intégrité de domaine, clef primaires et subrogées, clefs étrangères et leur mode de gestion,
validation des données, assertions…) ;
 La sécurité d'accès aux données :
Il définit ou implémente l'accès aux données en autorisant des profils de connexion ayant faculté
d'exécuter certaines commandes dans certaines bases (gestion des privileges) ;
 La récupération de données :
Il doit s'assurer que le plan de sauvegarde mis en place est opérationnel et recouvrant. Pour ce faire
il doit auditer la fréquence de changement des données sensibles afin, par ses sauvegardes, de
pouvoir remonter une base à un point particulier du calendrier, à la suite d'une erreur fonctionnelle. Il
doit aussi et très régulièrement vérifier la consistance des sauvegardes et la faisabilité de la restauration
en expérimentant celle-ci dans des conditions proches de la réalité (gestion de désastre).
 La maintenance de base
Il doit vérifier que les espaces de stockage sont en bon état et dans le cas contraire les réparer. Il
doit défragmenter les structures de stockage et les index afin d'assurer un temps de réponse linéaire. Il
doit s'assurer de la bonne gestion des fichiers (données et journaux de transactions) afin que ces
derniers ne saturent pas les disques.
 La gestion des désastres (incidents) :
Il doit créer et tester des solutions de maintien de la continuité de la production (clusterisation, mise
en miroir, log shipping…) afin qu'en cas de sinistre matériel la production puisse redémarrer dans un
temps imparti prédéfini (quelques secondes pour les meilleures solutions)
 Le maintien de la performance :
Il assure que l'accès aux données se fasse dans un temps raisonnable et que cette performance soit
maintenue dans le temps. Il doit donc mettre en œuvre une veille sur les statistiques d'exécution et
réagir sur des allongements de temps de réponse en diagnostiquant le problème et en le résolvant si
celui-ci est de son ressort (procédures de maintenance, ajout de ressources physique, refactoring du
modèle de données…). Pour cela il dispose d'outils qui lui donnent des informations sur les objets les
plus utilisés et leur consommation de ressource lors des traitements (lecture, écritures, temps
CPU…).
 L'optimisation (et/ou le tunning) :
10
Il doit régulièrement et de manière pro-active faire des campagnes de mesure afin de débusquer les
problèmes de contention ou de temps de réponse avant qu'ils ne deviennent handicapants pour
l'exploitation et proposer les mesures nécessaires à les éradiquer : meilleurs gestion des transactions,
études d'indexation, statistiques, réécritures de requêtes.
 L'aide au développement et aux tests :

Il doit fournir un support aux équipes de développement. Par exemple, il peut fournir des jeux de
données en vue de tests (pris sur des bases en production), conseiller les développeurs sur les
techniques à utiliser afin d'obtenir les meilleurs performances d'emblée, voir participer à la
structuration de la base afin notamment d'implémenter les nouvelles fonctions. En dernier ressort, il
valide les demandes de modifications ou modification du schéma de la base ;
 La gestion des flux de données :

Il est responsable des problématiques d'import et d'export des données tant sur le plan des
ressources à y allouer que de la sécurité à mettre en œuvre.
 Migration et mises à jour :

Il doit régulièrement appliquer les mises à jour préconisées (système et SGBD) et assurer la
migration des bases par exemple dans le cas d'un changement de serveur.
L’Administrateur Système :
En informatique, le titre d'administrateur systèmes désigne la personne responsable des serveurs d'une
organisation (entreprise, association, administration).
Il travaille au sein d'une DSI (Direction des Systèmes d'Information) ou d'une SSII (Société de
Services en Ingénierie Informatique). L'administrateur systèmes intervient auprès du DSI, des DBA
(Database Administrator, administrateur de bases de données), des administrateurs réseau, des
webmasters et apparentés, des développeurs, des responsables bureautique (postes de travail) et enfin
des usagers. Il est responsable de la disponibilité des informations au sein de son entreprise. Son rôle
ne se limite pas à la résolution des problèmes, mais il doit proposer des solutions en adéquation avec
les besoins de son client.
Les savoir-faire en administration des systèmes incluent la connaissance des systèmes

d'information et de la manière dont les gens les utilisent dans une organisation. Ceci comprend à la
fois une certaine connaissance des systèmes d'exploitation et des logiciels applicatifs, ainsi que le
dépannage matériel et logiciel.
Toutefois, la compétence la plus importante pour un administrateur de système est la

résolution des incidents. On fait souvent appel à un administrateur quand un système d'information
ne fonctionne plus ou mal, celui-ci doit être capable de faire un diagnostic exact et rapide du
11
dysfonctionnement, puis de trouver le meilleur moyen d'y remédier.
Les administrateurs système ne sont pas des architectes logiciels ni des développeurs. En
général, on ne leur donne pas de missions de conception et d'implémentation de nouvelles
applications. Néanmoins, ils doivent comprendre le comportement des logiciels afin de les déployer
et de régler différents problèmes les touchant. La connaissance de différents langages de
programmation de scripts et d'automatisation de routines (Powershell, Bash et Perl ou Python)
leur est souvent nécessaire.
Dans le cas des systèmes connectés à Internet ou des systèmes métier fortement critiques, un
administrateur doit être compétent en sécurité informatique. Ceci inclut non seulement le
déploiement de correctifs, mais aussi prévenir les pannes et autres problèmes de sécurité. Dans
certaines organisations, il existe un administrateur système spécialisé en sécurité qui s'occupe des
pare-feu et des systèmes de détection d'intrusion mais les administrateurs sont généralement
responsables de la sécurité dans leur service.
 l'installation
 Le paramétrage
 Le maintien
 La mise à jour
 L’évolution
 La sauvegarde
 La restauration
 La planification
 La supervision
 Le conseil
 Le support
 La veille technologique dans le périmètre technique des matériels et logiciels de type
serveur, principalement les systèmes d'exploitation.
Il a parfois la tâche de l'administration du réseau et/ou de l'administration des bases de données dans
des organisations de petite taille.
L’Administrateur Réseau :
Un administrateur réseau est une personne chargée de la gestion du réseau, c'est-à-dire de gérer les
comptes et les machines d'un réseau informatique d'une organisation (entreprise par exemple). Cela
12
peut concerner notamment des concentrateurs, commutateurs, routeurs, modems, pare-feu, proxy,
connectivité Internet, les réseaux privés virtuels (VPN). Il est souvent assisté d'un ingénieur
architecte informatique qui conçoit une architecture réseau.
L'administration de réseau est une discipline de l'informatique qui peut éventuellement s'étendre
à la téléphonie.
L'administrateur réseau est parfois également administrateur système, il gère alors également les
postes de travail (poste client), imprimantes et serveurs de l'entreprise.
 Gestion du câblage réseau (connexion physique entre plusieurs machines) ;

 Gestion du routage (connexion logique entre l'intérieur et l'extérieur du réseau ou entre plusieurs
sous- réseaux) ;
 Gestion de la sécurité (protection antivirale, pare-feu, prévention des intrusions etc.) ;
 Gestion des droits d'accès des utilisateurs (accès au réseau, etc.).
L'administrateur réseau veille à ce que tous les utilisateurs aient un accès rapide au système
d'information de l'entreprise. Il n'intervient pas, excepté pour les petites structures, dans la
conception de l'architecture du réseau, tâche dévolue à un ingénieur spécialisé (architecte
réseau). Un administrateur réseau est une personne qui crée le réseau informatique pour
l’entreprise. Au jour le jour, il gère l'utilisation du réseau.
C'est lui qui donne l'autorisation aux nouveaux utilisateurs à se connecter. L’une de ses
taches les plus importantes est de veiller à la sécurité et à la sauvegarde des données sur
le réseau.
 Compétences requises :
- Il faut avoir un sens de la logique,
- Être minutieux et trouver une solution à des problèmes rapidement et le plus souvent à distance.
- Un administrateur n’a généralement pas d’horaire fixe. Il travaille le plus souvent dans son
bureau, c’est de là qu'il gère les problèmes qui surviennent dans l’entreprise.
- Il doit réagir de toute urgence pour identifier la cause de l'incident, puis effectuer les
réparations nécessaires dans les plus brefs délais.
- L'administrateur réseau doit assurer une constante veille technologique, et tester des
nouveaux matériels pour les insérer, si besoin, dans son système.
- L’administrateur réseau travaille avec un ou plusieurs techniciens en informatique.
13
L’ingénieur de production exploitation :

Met en œuvre et assure la disponibilité des ressources physiques (serveurs, disques, automates,
...) et des ressources logiques (logiciels, espaces disques, puissance...) nécessaires au
fonctionnement des systèmes de production et d'exploitation informatiques et télécoms de
l'entreprise.
Surveille le fonctionnement des différents systèmes, réseaux, ... selon les normes et les méthodes
d'exploitation et de sécurité. Peut coordonner une équipe.
Taches principales :
 Il peut assurer tout ou une partie de ces taches :

 Ordonnancer le déroulement des travaux et mettre en œuvre les traitements
d'exploitation/production des ressources informatiques
 Superviser et vérifier l'état des ressources informatiques, réaliser les sauvegardes et les archivages
de données
 Contrôler le fonctionnement d'un outil ou équipement
 Réaliser la maintenance de premier niveau de matériel informatique
 Contrôler le déroulement de travaux
 Diagnostiquer la nature et l'origine des incidents et mettre en œuvre les mesures correctives
 Planifier des interventions de maintenance
 Contrôler une opération de maintenance
 Installer et intégrer le matériel (station, équipement réseau, périphériques, ...) dans
l'environnement de production et configurer les ressources logiques et physiques
 Effectuer une assistance technique
 Traiter l'information (collecter, classer et mettre à jour)
 Surveiller le fonctionnement : d'applicatifs et logiciels, de bases de données, de couches logiciels,
d’espaces disques, réseaux de Télécoms, réseaux informatiques, des serveurs, de systèmes
 Créer des droits d'accès, des comptes utilisateurs en fonction des profils
 Suivre l'état des stocks
 Définir des besoins en approvisionnement
 Préparer les commandes
 Suivre et contrôler la conformité des interventions de prestataires de maintenance
 Préconiser des choix techniques ou effectuer des prévisions d'acquisition d'équipements
informatiques, d'applicatifs
 Suivre et gérer un parc d'équipements informatiques et organiser des salles informatiques
 Superviser et organiser les travaux d'exploitation/production informatique
14
 Coordonner l'activité d'une équipe

Compétences requises :
 Connectique, Architecture des systèmes d'information, Analyse de la performance, Analyse

d’incidents, Métrologie, Normes rédactionnelles, Normes et standards d'exploitation, Normes
qualité, Règles de sécurité Informatique et Télécoms, Infogérance / télémaintenance, Gestion de
projet, Procédures de maintenance…
 Système d'exploitation Windows, AS 400, HP-Ux, IBM Aix, Unix, Linux, MacOS, MVS, Solaris
...
 Ainsi que les techniques d'animation d'équipe (axe communication)
15
Annexes
Annexe I : Planification
Les objectifs de la planification sont les suivants :
 Déterminer si les objectifs sont réalisés ou dépassés


 Suivre et communiquer l’avancement du projet

 Affecter les ressources aux tâches
Diagramme de GANTT (planning à barres)
C’est un calendrier sur lequel chaque activité est représentée par une barre grisée débutant
à la date de début au plus tôt et terminant à la date de fin au plus tard, sur laquelle glisse
une barre blanche correspondant aux dates réelles de début et de fin.
Le diagramme de GANTT est une représentation graphique permettant de renseigner
et situer dans le temps les phases, activités, tâches et ressources du projet.
Les tâches peuvent se succéder ou se réaliser en parallèle entièrement ou partiellement.
Planning Prévisionnel
Exemple : Fabrication d’une table. Pour fabriquer une table, on doit fabriquer les quatre
pieds et la surface puis les assembler. La fabrication des quatre pieds (représentée dans le
diagramme par les tâches T1, T2, T3, T4) peut se faire en même temps. La fabrication de la
surface (T5) peut être lancée au même moment que les pieds. Par contre pour les assembler
(T6) il faut que les cinq tâches précédentes soient finies.
Au niveau des ressources humaines, pour fabriquer la table en correspondance avec ce

diagramme, il nous faudrait cinq personnes pour exécuter les tâches T1 à T5 en parallèle et
une sixième ou de préférence l’une des cinq précédentes pour exécuter la sixième tâche.
Remarque : Le losange noir qu’on remarque sur le diagramme est ce qu’on appelle un
jalon. Les jalons d’un projet se définissent comme :
 Des événements clé d’un projet, montrant une certaine progression du projet

 Des dates importantes de réalisation d’un projet

 Une réalisation concrète (production de livrables)
16
Tâches
T1
T2
Tâches en
T3 Parallèle
T4
T5
T6
Jalon
Temps
Au début du projet le planning est prévisionnel au fur et à mesure que le projet avance
le planning est mis à jour périodiquement. Pour passer du prévisionnel au réalisé en se base
sur certaines étapes intermédiaires qui sont les tableaux de bord et les rapports d’activité.
es
 Tableau de bord :C’est un fichier où on note les événements imprévus qui
cesont produits et qui ont une incidence sur le projet.
Ces événements peuvent être liés aux ressources humaines, aux progiciels, aux bugs
dans l’application, au matériel et autre.
Remarque : Ne pas confondre l’application qu’on développe et les progiciel qu’on utilise pour
la développer (java, oracle, …etc.)
 Rapport d’activité :il contient :
 Planning prévisionnel
 Tableau de bord
 Rapport d’activité lié à chaque ressource humaine représentantce qui
a été fait réellement.
17
Tâches
T1
T2
Tâches en
T3 parallèle
T4
T5
T6
Jalon
Temps
Les outils de planification : MSPROJECT, PMW (Project Management Workbench)
qui est devenu NIKO, PSN7,…etc.
Annexe II : Les réunions

 Périmètre de la réunion
Les réunions doivent avoir un ordre du jour c’est à dire les différents sujets à traiter
et les temps impartit à chacun. Par souci d’efficacité, les participants sont triés selon l’ordre
du jour.
 Organisation générale
Pour organiser une réunion il faut d’abord convenir d’une plage horaire qui arrange
tous les participants, ce qui n’est pas toujours facile. Cependant des outils comme Lotus ou
même Outlook sont là pour nous faciliter la tâche. En effet, ces outils disposent des agendas
de toutes les personnes ainsi que des disponibilités des salles de réunion, il suffit de repérer la
date et la plage horaire qui convient à tout le monde. Si on n’y arrive pas et qu’on a des jalons
à respecter, on choisit la date qui réunit le plus grand nombre de personnes en donnant la
priorité bien sûr aux personnes indispensables puis on prévient les participants en diffusant
l’ordre du jour, la date et l’heure de la réunion. La confirmation peut se faire soit par mail soit
par appel téléphonique. Une fois 80% au moins des personnes sollicitées, dont
impérativement toute les personnes indispensables, ont confirmé leur présence on réserve la
salle de réunion selon sa capacité et les moyens dont on aura besoin.
18
 Le compte rendu
Le compte rendu de la réunion, rédigé en général par l’organisateur ou le demandeur
de la réunion sinon par une personne désignée, est envoyé pour action (validation) à tous les
présents et pour information aux responsables et aux absents. Il est conseillé de le rédiger
immédiatement après la réunion.
Dans la diffusion du compte rendu il faut préciser la date à partir de laquelle, sans
remarques du destinataire, le compte rendu est considéré comme validé.
 Types de réunions
Les interviews
Rencontres entre l’expert métier et l’assistant MOA qui permettent à ce dernier de

mieux comprendre les fonctionnalités de l’application afin de mieux les expliquer à l’équipe
MOE et rédiger la SFG.
Réunions fonctionnelles
Elles ne touchent que l’aspect métier de l’application. Leur but est de clarifier
certaines fonctionnalités et règles de gestion contenues dans la SFG. On a en moyenne une
réunion par fonctionnalité. Leurs ordres du jour doivent rester purement fonctionnels. La
fréquence des réunions fonctionnelles est hebdomadaire pour les projets en création et
mensuelle pour ceux en maintenance. Participent aux réunions fonctionnelles les chefs de
projets MOA et MOE et les assistants MOA et MOE. Les comptes rendus de ces réunions
permettent aux assistants MOE de rédiger les SFD (Spécifications Fonctionnelles Détaillées)
appelées aussi les AFD (Analyses Fonctionnelles détaillées).
Réunions de suivi
D’une périodicité hebdomadaire pendant la phase de développement et mensuel

pendant la phase de maintenance, les réunions de suivi son demandées par la MOA et ont
pour but le suivi de l’évolution du projet. Sont conviés à ces réunions d’une durée d’une
demi-heure les CPMOA, CPMOE, les assistants MOA et MOE.
Des réunions de suivi moins formelles sont aussi organisées entre l’assistant MOE et
les développeurs pour permettre aux premiers de s’acquérir de l’état d’avancement du
développement. Dans les entreprises les plus aisées des réunions d’équipes aussi sont
organisées périodiquement.
Réunions de pilotage
19
D’une périodicité mensuelle en période de développement et semestrielle en période

de maintenance, elles se déroulent entre les assistants MOA et MOE, leur but étant de diriger
le projet et discuter de l’aspect budgétaire.
Annexe III
Le modèle entité-association (Le model conceptuel de données)
Le modèle EA est un outil qui permet la conception graphique d’un système

d’information, comme une base de données par exemple : c’est un ensemble de conventions
graphiques qui permettent de représenter la partie statique d’un système d’information.
Entités :
Une entité est une catégorie d’objets ayant un nom générique et partageant des propriétés
communes.
Associations :
Une association est un lien qui relie au moins 2 entités.
Cardinalité :
La cardinalité est une notion permettant de définir la relation d’une entité par rapport à une
autre. Elle est définie par une borne minimale et une borne maximale pouvant prendre les
valeurs 0, 1 ou n.
Entités
Clé primaires
Personne Voiture
N° de SS N° d’immat.
Nom 1,n Appar 1,n Couleur
Prénom tient
Association binaire
Adresse
Cardinalités
Attributs (Propriétés)
Le modèle conceptuel de données (MCD) aboutit à un modèle physique de données
(MPD) qui est la base de données. Les entités ainsi que certaines associations deviendront des
tables.
Passage du MCD au MPD
Si on prend l’exemple précédant on remarque que les cardinalités maximales des deux
entités ont la valeur n, une personne peut avoir une ou plusieurs voitures et une voiture peut
appartenir à une ou plusieurs personnes. Cela implique que l’association d’appartenance dans
le MCD deviendra une table dans le MPD au même titre que les entités « Personne » et «
voiture ». Elle aura comme identifiant une clé composée des deux clés des deux entités.
20
Personne Appartient Voiture
N° de SS N° de SS , N° d’immat. N° d’immat.
Nom Couleur
Prénom
Adresse
Dans le cas où on avait une cardinalité 1,1 du côté de l’entité personne et une
cardinalité 1,n du côté de l’entité voiture, l’association ne deviendra pas une table mais la clé
de la table Personne migrera vers la table voiture et deviendra une clé candidate de cette table.
Personne
N° de SS Voiture
Nom N° d’immat.
Prénom N° de SS
Adresse Couleur
Dans le cas où on avait une cardinalité 1,1 des deux côtés alors la clé primaire de
chacune des deux tables migre vers l’autre table.
Personne Voiture
N° de SS N° d’immat.
N° d’immat. N° de SS
Nom Couleur
Prénom
Adresse
Pour obtenir un schéma dans lequel les erreurs de mises à jour (d’insertion, de
modification et de suppression) ainsi que les redondances logiques sont les plus limitées
possibles on utilise un certain nombre de règles.
21
 Chaque entité doit avoir un identifiant (clé) élémentaire (non composé).

 Tous les attributs autres que l’identifiant doivent être en dépendance fonctionnelle
complète et directe de l’identifiant.
 Une association ne doit pas avoir d’identifiant.
 Un bon modèle conceptuel de données est un modèle qui ne contient pas ou peu de
relation n-aire.
Le modèle de données est accompagné d’un dictionnaire de données qui définit
chaque propriété qui apparaît sur ce modèle. Dans le choix des noms des propriétés, il faut
éviter les homonymes.
Dans une base de données où le SGBD codifie les noms des tables, il faut avoir un
tableau qui fait la correspondance entre les vrais noms des tables et les codes.
Il faut savoir que chez les grands comptes le MCD contient 100 à 200 entités et le
MPD 200 à 300 tables. Parmi ces dernières on distingue les tables de référence (client,
fournisseur, salarié) qui sont relativement constantes et peu volumineuses et les tables de
mouvements (facture, commande) qui sont variables et très volumineuses (de 1 à 2 millions
d’enregistrements).
La performance dans une application en informatique de gestion est très liée à la
volumétrie de la base de données. Les BD de test ne dépassent pas le volume de 10 GO. Par
contre le volume d’une BD de production est entre 200 GO et un TO.
Pour améliorer les performances d’une base de données, en plus des règles du MCD
citées ci-dessus, on peut rajouter :
Optimiser les requêtes en évitant les « in » et les « not in ».
Commencer les tables les moins volumineuses dans les « select in ».
Cas particulier :
Les Info centres sont des applications qui servent à faire des statistiques. Ce sont des
dépôts de données de plusieurs applications d’où un problème de volumétrie. Pour améliorer
leur performance on doit dénormaliser en enregistrant les résultats des requêtes les plus
demandées.
22
Annexe IV : Définitions
1. Les types de programmes
On peut distinguer trois types de programmes informatiques :
Les programmes transactionnels (ou IHM ou écran).
Les programmes batchs.
Les programmes d’état.
Les programmes transactionnels TP
Un TP (ou IHM ou Ecran) est un programme qui nécessite l’intervention de l’homme
pour s’exécuter. Ce qui fait que les mises à jour de la base de données sont limitées. Dans une
application il y a au moins deux cents IHM donc par souci de cohérence et d’esthétique une
charte graphique est nécessaire. Elle est rédigée par l’assistant MOA. Plusieurs types d’IHM
existent :
 Les écrans listes : Sont des écrans qui contiennent en général pas plus que dix
lignes dans lesquelles elles résument un certain nombre d’enregistrements.
 Les écrans fiches : Sont des écrans qui affichent le détail d’un enregistrement
à la fois.
 Les écrans de mise à jour : Sont des écrans qui nous permettent d’insérer, de
supprimer ou de modifier des enregistrements
 Les écrans de consultation : Sont des écrans qui nous permettent de consulter
un certain nombre d’informations sur les enregistrements selon les
habilitations.
Les Batchs
Les batchs sont des traitements de mises à jour de masse entièrement automatisés. Ils
mettent à jour des milliers d’enregistrements sur une même table. Ces mises à jour très lentes
peuvent engendrer un ralentissement des TP. Pour ne pas faire concurrence aux TP, les batchs
de traitement de masse se lance aux heures de fermeture des TP, généralement la nuit. Dans le
cas où un batch de nuit indispensable au fonctionnement des TP plante, on informe les
utilisateurs de la fermeture des TP et on relance le batch pendant la journée en essayant de
pénaliser le moins possible l’utilisateur final (on le lance entre 12h et 14h ou tôt le matin par
exemple).
23
En cas d’erreurs dans les enregistrements le batch crée un journal d’exécution appelé aussi
log ou rapport d’activité d’exécution qui est un état[5] des erreurs fonctionnelles, pas
techniques. Cela dit, le seuil d’erreurs toléré pour le fonctionnement d’un batch est de 2%.
Le chronogramme :
C’est un outil qui permet l’ordonnancement des batchs à exécuter pour qu’ils puissent
tous passer la nuit avant l’ouverture des TP. Le service études se charge de demander au
service exploitation et production de réaliser le chronogramme via des outils spécialisés
comme Dollar Universe.
Il existe différents types de batchs :
 Les batchs d’alimentation (d’alim)

Ce sont des batchs périodiques qui servent à alimenter la base de données ce qui
implique la gestion de la structure de données entre la source et la base.
 Les batchs d’initialisation (d’init)
C’est le premier batch d’alimentation qui initialise la base de données qui était vide à
l’origine.
 Les batchs de purge
Sert à enlever les données de la base qui sont inutiles, incohérentes ou redondantes et
cela à la demande de l’utilisateur.
Exemple : En cas de refonte de la base de données (base qui ne respecte pas les
formalismes), on fait une purge des données inutiles dans l’ancienne base à l’aide
d’un batch de purge. Puis on fait une reprise des données restantes donc utiles en
utilisant un batch de reprise de données ensuite on initialise la nouvelle base à l’aide
d’un batch d’initialisation en prenant en compte la nouvelle structure des données et
en respectant les formalismes.
 Les batchs jetables
Batchs qu’on utilise qu’une seule fois comme celui d’initialisation ou de reprise
de données en cas de refonte de la base.
 Les batchs d’interface
Interviennent entre deux applications en générale et ils sont de deux types :
Batchs d’extraction de données
Batchs d’intégration de données
24
Exemple : Pour informer le service comptabilité des nouvelles factures enregistrées on

doit transférer ces nouvelles factures du serveur de l’application facturation au serveur de
l’application comptabilité.
Batch Batch
Base de Base de
d’extraction d’intégration
données Données
Facturation Comptabilité
Factu Factu
CFT
re.txt re.txt
Deamon 2
Deamon 1
Serveur A Serveur B
Du côté de la première application (Facturation), un batch d’extraction se lance

périodiquement pour extraire les nouvelles factures et les enregistrer sous un fichier plat dans
un répertoire bien défini. Dès la création du fichier, celui-ci est repéré par un deamon qui
surveille le répertoire parent et transféré à l’aide du logiciel CFT (Cross File Transfert) au
serveur de l’application comptabilité.
Du côté de la deuxième application (Comptabilité) un autre deamon guète l’arrivé de
fichiers dans un répertoire défini et dès que celui-ci est reçu le deamon déclenche le
lancement du batch d’intégration qui insert les données du fichier dans la base de
l’application comptabilité.
Dans le souci du respect de la structure de données, le format du fichier plat est spécifié
par le demandeur.
25
Service Facturation Service comptabilité

Fait la demande pour
l’envoi permanent des
MOA nouvelles factures MOA
Avertit la MOE Spécifie le format du Avertit la MOE
fichier et sa structure
MOE MOE
Indique la périodicité du
lancement du batch
Avertit la Prod. Avertit la Prod.
Prod. Envois des fichiers Prod.
26
Les états
Sont des programmes qui nous donnent des écrans de consultation, des logs ou des
journaux d’exécution, des factures, des fiches de paies …etc.
Les outils permettant de créer des états sont nombreux : parmi eux, on peut citer Crystal
Report, Business Object ou bien encore Cognos.
2. Anomalie (ano)
C’est une règle de gestion décrite dans la SFG et les SFD qui n’a pas été respectée dans
le développement de l’application.
Fiche d’anomalie :
Numéro de l’anomalie
Nom du projet
Environnement de test dans Nom du rédacteur de

lequel elle a été trouvée la fiche (Clé)
Degrés d’urgence si elle Bloquante

n’est pas bloquante
Libellé court de l’anomalie

en quelques phrases
Explication détaillée de l’anomalie en s’appuyant sur les SFD, SFG, les

schémas, les copies d’écran…etc.
Commentaire du développeur
Pourquoi cette anomalie est survenue ?
Le temps de correction
Quelles sont les tables et le module concernés ?
Commentaire du testeur
OK : L’anomalie est corrigée
KO : L’anomalie n’est pas corrigée, ce qui marche pas.
27
Une anomalie est dite bloquante lorsqu’elle est incontournable. La moins bloquante est
l’anomalie de forme (orthographe, couleur … etc).
En phase de maintenance ou en production on parle d’incident plutôt que d’anomalie.
3. Evolution (évo)
On distingue deux types d’évolution :
Evolution mineure (release) : Ajout d’une ou plusieurs règles de gestion.
 Evolution majeure : Ajout d’une ou plusieurs fonctionnalités, elle peut faire l’objet d’un
projet à elle seule (rédaction de la SFG, SFD, …etc).
Fiche d’évolution mineure :
La fiche d’évolution mineure est la même que celle d’anomalie sauf qu’on y trouve
pas l’environnement de test et elle ne peut pas être bloquante puisque l’évolution n’est pas
encore développée.
4. Avenant
C’est le changement ou la modification d’une règle de gestion. Il est plus cher qu’une
évolution mineure.
Fiche d’avenant :
C’est la même que la fiche d’évolution mineure.
La MOA ou l’utilisateur essaie toujours de faire passer une évo mineure pour une ano
et un avenant pour une évo mineure.
5. Environnements de travail
C’est l’ensemble des couches matériel (serveur), d’application (BD et programmes) et
logiciel (système d’exploitation, SGBD, langage de programmation,…etc)
On distingue 5 environnements de travail différents dans un projet d’envergure à savoir :
Environnement de développement :
Dédié aux développeurs pour faire les tests unitaires (module par module).
E. d’intégration :
Utilisé par l’assistant MOE pour effectuer ces tests. La qualité des données est meilleure
que celle des tests unitaires.
E. de recette :
Utilisé par les assistants MOA pour effectuer leurs tests. Les données sont encore
meilleures que celles d’intégration.
E. de préproduction :
28
Se trouve au sein du service de production. La préproduction a pour objectif de stabiliser

les couches avant la production.
E. de production :
Une fois que les tests sont concluants au niveau de la préproduction, l’environnement de
celle-ci devient l’environnement de production avec des données réelles.
La diversité des environnements de travail est due au fait qu’on a des soucis
différents selon les niveaux, les soucis et critères des développeurs sont différents de ceux
des analystes par exemple.
6. Lotissement
On appelle lot ou lotissement chaque partie du projet qui est indépendante des
autres. Un lot achevé peut être livrable. Certaines fonctionnalités d’une application peuvent
être complètement indépendantes des autres et donc constituer des lots. De même qu’une
évolution majeure d’un projet est considérée comme un lot. La difficulté est de pouvoir
définir les frontières entre les différents lotissements
7. Support utilisateur
On parle de support utilisateur lorsque le nombre d’utilisateur est limité (inférieur à
20). Dans ce cas il s’occupe de l’aspect applicatif et non applicatif de l’application.
Lorsque l’ordre d’utilisateurs est de plusieurs centaines voire plusieurs milliers, on
parle de support utilisateur niveau 1. Dans ce cas là le support est seulement non applicatif.
L’applicatif est pris en charge par le support utilisateur niveau 2.
Le support utilisateur est souvent l’assistant MOA.
Comment assister un utilisateur ? Vérifier l’origine du problème en cherchant
respectivement si le problème est matériel, sinon progiciel et en fin applicatif.
 Problème matériel : Si le souci est seulement au niveau du poste, diriger l’utilisateur
vers le service micro et réseaux. S’il est au niveau du serveur, le diriger vers le DBA
et si le problème est lié au serveur lui-même, contacter le constructeur.
Problème progiciel : Si le souci provient d’un progiciel, prévenir l’éditeur.
 Problème applicatif : Dans le cas où le problème concerne les données, on s’adresse à

l’expert métier qui est l’administrateur des données, s’il concerne les traitements on
remplit une fiche incidente et l’envoie à la MOE. L’incident est alors traité comme
une anomalie.
29
8. Interlocuteurs et tâches des assistants MOA et MOE

 Les tâches de l’assistant MOA
Rédaction de la SFG

Rédaction de la charte graphique
Repporting pour le CPMOA
Répondre aux interviews de l’assistant MOE
Support fonctionnel pour l’assistant MOE
Validation des SFD

Rédaction du plan de test et échantillonnage des données

Il effectue les tests de recette, de non régression et de montée en charge
Gestion des anomalies et des évolutions

Suivi du projet

Participe aux réunions fonctionnelles et de suivi et rédige les comptes rendus
des réunions de suivi.
Rédaction du PV de recette

Rédaction du Manuel Utilisateur
Formation des utilisateurs finaux
Support utilisateur

 Ses interlocuteurs

L’expert métier : qui lui transmet les connaissances fonctionnelles du projet et lui
valide la SFG

Le Chef de Projet MOA : à qui il rend compte de l’état d’avancement du projet
(reporting).
L’assistant MOE : auquel il transmet la SFG et pour lequel il fait le
supportfonctionnel et valide les SFD

Utilisateurs finaux : l’assistant MOA se charge de l’assistance et de
laformation des utilisateurs finaux de l’application ;
Les Administrateurs de Base de Données (DBA) : au cas où la BD de données
 Recette tombe Les DBA s’occupe de l’administration de la base de données et de
la gestion de l’environnement de recette (DBA Etudes), de celui de la pré-
production et de la production (DBA Production) ;
L’intégrateur : ce dernier s’occupe de la livraison des différentes versions
L’application à l’assistant MOA.
 Les tâches de l’assistant MOE

30
Préparer et organiser des réunions fonctionnelles avec l’assistant MOA

Rédiger les comptes rendus des réunions fonctionnelles
Rédaction des SFD à partir de la SFG

Assurer le support fonctionnel des développeurs

Validation de l’analyse organique rédigée par l’ingénieur de développement
Rédaction du plan de test et échantillonnage de données
Effectuer les tests d’intégration, de non régression et de montée encharge
Gestion des anomalies et des évolutions

Assister la MOA dans la phase des tests de recettes
Assister aux réunions de suivi
Préparer l’environnement de formation des utilisateurs finaux
Assurer le suivi de la mise en production

Assurer le support utilisateur

 Ses interlocuteurs :

Le Chef de Projet MOE : l’assistant MOE informe le CPMOE sur l’état
d’avancement du développement, sur d’éventuels dépassement de délais ou de
charges, … etc.

L’assistant MOA : Il valide les SFD rédigées par l’assistant MOE. Ils se
voientlors des réunions fonctionnelles pour discuter de la SFG permettant de
rédiger les SFD. De plus, l’assistant MOE assiste l’assistant MOA lors des tests
de recette.
Les Développeurs : l’assistant MOE est le support technique des
ingénieursd’études et de développement.

Intégrateur : l’assistant MOE est en contact avec l’intégrateur pour la
gestiondes livraisons
Le service de Production : la production contacte l’assistant MOE
lorsqu’unincident arrive lors de la mise en production

Administrateur base de données (DBA) : ils discutent de l’évolution et de la
sauvegarde de la base de données. Le DBA Etudes s’occupe de la gestion de
l’environnement d’intégration.
 Les tâches de l’Ingénieur de Développement
Rédaction l’analyse organique à partir des SFD
Définition des normes de développement
Programmation
31
Débuguer les programmes

Il fait les tests unitaires
Maintenance de l’application.
 Ses interlocuteurs
Le CPMOE : le développeur informe son chef de projet sur
d’éventuelsdépassements de délais ou de charges ainsi que des problèmes
techniques rencontrées. Il l’informe de l’état d’avancement des différentes tâches
qui lui sont confiées (correction d’une anomalie, développement d’un module…etc.)
L’assistant MOE : l’assistant MOE rencontre le développeur lors des
réunionsinformelles. Aussi, c’est lui qui valide l’analyse organique rédigée par le
développeur et assure le suivi de l’avancement des anomalies et des évolutions
L’intégrateur : le développeur lui précise quels sont les programmes qui font
partiede quelle application et de quelle version, les scripts et programmes qu’il a
développés, ce qu’ils font et où est ce qu’ils se trouvent
Administrateurs de base de données : le développeur rencontre le DBA pour voir
lastructure des tables pour pouvoir optimiser les requêtes, transférer des données,
lui transmettre les scripts…etc.
Annexe V : Gestion des anomalies et des évolutions

La gestion des anomalies et des évolutions à consiste identifier les anomalies, les
corriger, rédiger les évolutions, les programmer et faire un suivi de tout cela. Elle s’effectue
donc aux niveaux de la MOE et de la MOA.
Gestion des anomalies : Gérer une anomalie c’est la suivre durant sesdifférentes
états qui sont ; Ouvert, en cours de validation et fermé.
Exemple : Un certain nombre d’anomalies (20) sont trouvées pendant les tests de recette
par l‘assistant MOA (anomalie n°1 à 20), il crée un fichier Excel de récapitulation qui
contient 3 feuilles correspondants aux trois états d’une anomalie, ce fichier servira à
suivre toutes les anos trouvées. Au début tous les anos sont dans l’état « Ouvert » donc
dans la feuille «Ouvert » les autres feuilles étant vides. I remplie les fiches anomalies
qu’il envoie à la MOE. L’assistant MOE, qui a trouvé pendant les tests d’intégration un
certain nombre d’anomalies (800 : de n° 1 à 800) et qui a donc un fichier Excel donc
seule la feuille «Fermé » est remplie puisque que les anos ont été déjà corrigées, rajoute
les 20 nouvelles anomalies dans la feuille « Ouvert » du n°801 au n°820 et fait un
tableau de correspondance entre ces numéros et ceux de l’assistant MOA. Ensuite ils
32
rédigent les fiches d’anomalies avec les nouveaux numéros et les transmet aux
ingénieurs de développement. Au fur et à mesure qu’une anomalie et corrigée
l’ingénieur de développement envois la fiche correspondante à l’assistant MOA qui
déplace l’anomalie de la feuille « ouvert » à la feuille «en cours de validation» et
l’envoi à son tour avec son numéro initial à l’assistant MOA qui déplace aussi l’ano
vers la feuille « en cours de validation». Une fois l’anomalie validée les assistants MOA
et MOE la mette définitivement dans la feuille «fermé».
Une gestion manuelle des anomalies est aussi faite en parallèle (version papier) en
utilisant un classeur et trois groupes de fiches correspondant aux trois états. Le reste est
exactement le même que par Excel.
Cependant des outils de gestion des anomalies existent, on peut citer par exemple
Continus ou un outil maison.
Annexe VI : Stratégie de sauvegarde des données

Elle dépend de la fréquence de mise à jour des données
1. La haute disponibilité des données
Cette stratégie est utilisée lorsque la fréquence de mise à jour des données est très élevée
et qu’on ne peut pas se permettre de perdre la moindre donnée. Elle nous assure une
permanente disponibilité des données. Par exemple dans la monétique la fréquence de maj est
très élevée. On ne peut pas se permettre de perdre une seconde de données car beaucoup de
transaction peuvent être faites durant cette seconde et cela peut représenter une très grande
somme d’argent. On peut alors avoir deux ou plusieurs serveurs qui contiennent les mêmes
données on appelle cela le clustering.
2. La sauvegarde incrémentale
Cette stratégie est utilisée lorsque la fréquence de mise à jour des données n’est
pas très élevée et qu’on peut se permettre de perdre un certain nombre de données.
Exemple : Données de comptabilité
33
On se donne les hypothèses suivantes : On peut se permettre de perdre une journée de

données et on ne travaille pas les w .e.
Elle consiste sur une semaine à récupérer les données du vendredi de la semaine
passée, le lundi, y rajouter celles du jour. Le mardi, mercredi et jeudi on sauvegarde
seulement le différentiel c à d celles du jour même. Le vendredi on récupère et sauvegarde les
données de toute la semaine et on efface les anciennes sauvegardes.
Différentiel
L M M J V S D
Annexe VII : Typologie des projets

Deux types de projets informatiques :
1. Les projets de fusion :

Ce qui nous concerne dans la fusion entre deux ou plusieurs sociétés est la fusion des
systèmes d’information, on peut distinguer deux cas :
Elles font le même métier :
Souvent dans ce cas on retient le système d’information de l’une d’elles et on migre

les données de l’autre. L’assistant MOA rédige les règles de migration et fait la
correspondance entre les données dans le système source et leurs équivalentes dans le système
destination. Le développeur s’occupe du développement des batchs (jetables) d’extraction et
d’intégration. (Voir Les projets de migration de données).
Elles ont deux métiers complémentaires :
On garde les deux systèmes d‘information.
34
2. Les projets de refonte :

Refonte fonctionnelle :
Suite à des restrictions fonctionnelles imposées par les règles de gestion de l’ancien
système d’information, l’utilisation de l’application est limitée et donc l’utilisateur se trouve
des fois dans l’impossibilité d’effectuer certaines opérations. La seule manière d’y remédier
est de changer les règles de gestion et donc de faire une refonte fonctionnelle.
Souvent une refonte fonctionnelle est suivie par une refonte technique mais des fois et
pour différentes raisons le client exige qu’on garde le même environnement technique.
Refonte technique :
Concerne le changement d’outils de développement, de langage, de BD ou de système

d’exploitation. Une refonte technique est souvent précédée par une refonte fonctionnelle.
Dans le cas où la refonte est seulement technique on parle de Refonte iso-fonctionnelle et
les seuls tests qu’on pourra faire seront des tests de non régression. La tâche du développeur
s’il n’y a pas de revue de code est d’adapter le code.
Etapes d’une refonte :

étude de l’existant
Critique de l’existant
Proposition de solutions
Choix d’une solution
Si la refonte est fonctionnelle et technique on reprend toute la démarche d’unprojet
depuis la SFG. Si la refonte n’est que technique on revoit ou on réadapte directement le code.
3. Les projets de migration :

On trouve deux types de migrations :
Migration de données :
La migration d’un système d’information à un autre, elle se fait suivant ses étapes :
Etude des structures de données des systèmes source et cible
Ecrire les règles qui permettent la migration de données du système source vers le
système cible
Développement des interfaces jetables
Les tests de simulation : faire les tests jusqu’à ce que les rejets tendent vers zéro.
35
Migration technique :
Consiste en le changement des outils de développement, de langage, de BD ou/et de
système d’exploitation. On peut dire qu’elle est équivalente à la refonte technique. La
migration technique peut être de deux types :
 Migration mineure (release) :
Concerne par exemple les évolutions mineures dans les versions en gardant le même éditeur :
version 7.1.4 vers version 7.2.4 SQL server 7 vers SQL server 2000.
 Migration majeure :
Concerne par exemple une évolution majeure dans la version : version 7.1.4 vers 8.0.0
4. Les projets d’études d’impact :
C’est étudier l’impact d’un changement sur un système d’information. Sur les
programmes en particulier cela consiste à chercher dans les programmes impactés ceux qui
contiennent la chaîne de caractères à changer. Vient l’estimation des charges qui est
forfaitaire et par programme. On procède en fin à la modification des la chaîne dans les
programmes. Pour ce genre de projets on ne fait souvent que des test de non régression.
Renvois
[1] : MOA centralisée : Une seule MOA pour tous les départements de la société.
MOA décentralisée : Chaque département a son propre service MOA qui s’occupe de
ces besoins informatiques. Dans ce cas de figure la MOA ne s’occupe que des besoins de
son département.
[2] : 0,5 correspond la moitié du temps de travail d’une personne.
[3] : On parle de maîtrise d’oeuvre (MOE) quand il s’agit de projet d’envergure. Dans le cas
de projets de maintenance ou de petits projet on parle de plutôt de développement.
[4] : Charge de travail d’un projet : La charge de travail est la quantité de travail nécessaire
pour effectuer une ou plusieurs tâches.
Délai : Le délai est le temps au bout duquel une ou plusieurs tâches sont effectuées
[5] : Un état est un fichier qu’on ne peut que consulter : exemple : une facture.
[6] : L’indentation est la hiérarchie des blocs et des instructions dans un programme.
[7] : Dans un programme bien structuré, les commentaires ne doivent pas représenter plus que
8% de la totalité du code. Au lieu de s‘étaler sur l’explication d’une partie du code,
l’ingénieur de développement doit faire des renvois vers l’analyse organique.
33
36
Démarche d’un projet Informatique
[8] : La gestion des anomalies et des évolutions, les réunions de suivi ainsi que les réunions de
pilotage ne sont des étapes proprement dites du projet mais des tâches qui s’effectuent tout au
long du projet.
[9] : Le tuning consiste à gérer et synchroniser les différents éléments d’une architecture
informatique en vue de l’optimisation des ressources mises en œuvre.
[10] : L’intégrateur est une personne qui connaît le fonctionnel et le technique. Il peut être
transverse à plusieurs projets ou appartient à une équipe.
37

Demarche Projet Production

Transféré par

Informations du documentcliquez pour développer les informations du document

Droits d'auteur :

Formats disponibles

Demarche Projet Production

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Demarche Projet Production

Transféré par

Droits d'auteur :

Formats disponibles

Démarche d’un projet Informatique (prod/system)

Démarche projet informatique

Table des matières

7. Support utilisateur ............................................................................................................................ 29

 La culture PROD/SYSTEME (historique) :

c’est une information critique.

2. Les services qui participent à un projet informatique

Le Service de Production et d‘Exploitation

A ce niveau les applications sont opérationnelles avec des données réelles.

Le Service Micros et Réseaux

3. Les étapes d’un projet informatique :

Version du Contenu Contenu technique Contenu technique

1.0.0 1.0.0 Spec de 1 à 30 Script de 1 à 200 Prog de 1 à 200

4. Les ressources du service PROD/SYSTEME :

Au niveau d’un projet informatique on distingue deux profiles :

Il peut assurer tout ou une partie de ces taches :

 La mise en place de standards, préconisation et bonnes pratiques :

 L'évaluation des besoins et de la qualité :

 La définition et la gestion des espaces de stockage :

 L'intégrité des données :

 La sécurité d'accès aux données :

 La gestion des désastres (incidents) :

 L'optimisation (et/ou le tunning) :

 L'aide au développement et aux tests :

 La gestion des flux de données :

 Migration et mises à jour :

Les savoir-faire en administration des systèmes incluent la connaissance des systèmes

Toutefois, la compétence la plus importante pour un administrateur de système est la

dysfonctionnement, puis de trouver le meilleur moyen d'y remédier.

Il peut assurer tout ou une partie de ces taches :

Il peut assurer tout ou une partie de ces taches :

 Gestion du câblage réseau (connexion physique entre plusieurs machines) ;

- Il faut avoir un sens de la logique,

L’ingénieur de production exploitation :

 Il peut assurer tout ou une partie de ces taches :

 Coordonner l'activité d'une équipe

 Connectique, Architecture des systèmes d'information, Analyse de la performance, Analyse

 Déterminer si les objectifs sont réalisés ou dépassés

Au niveau des ressources humaines, pour fabriquer la table en correspondance avec ce

Annexe II : Les réunions

Rencontres entre l’expert métier et l’assistant MOA qui permettent à ce dernier de

D’une périodicité hebdomadaire pendant la phase de développement et mensuel

D’une périodicité mensuelle en période de développement et semestrielle en période

Le modèle EA est un outil qui permet la conception graphique d’un système

Passage du MCD au MPD

 Chaque entité doit avoir un identifiant (clé) élémentaire (non composé).

 Les batchs d’alimentation (d’alim)

Exemple : Pour informer le service comptabilité des nouvelles factures enregistrées on

Du côté de la première application (Facturation), un batch d’extraction se lance

Service Facturation Service comptabilité

Prod. Envois des fichiers Prod.

Environnement de test dans Nom du rédacteur de

Degrés d’urgence si elle Bloquante

Libellé court de l’anomalie

Explication détaillée de l’anomalie en s’appuyant sur les SFD, SFG, les

Se trouve au sein du service de production. La préproduction a pour objectif de stabiliser

 Problème applicatif : Dans le cas où le problème concerne les données, on s’adresse à

8. Interlocuteurs et tâches des assistants MOA et MOE

Préparer et organiser des réunions fonctionnelles avec l’assistant MOA