FRFR Erp 04

Chapitre 4 : Réalisation et contrôle du projet au cours des phases…
CHAPITRE 4 : REALISATION ET CONTROLE

DU PROJET AU COURS DES PHASES
DE CONCEPTION, DE DEVELOPPEMENT
ET DE DEPLOIEMENT
Objectifs
Les objectifs de ce chapitre sont les suivants
• Découvrir comment planifier dès le départ la phase de déploiement

en créant un plan de déploiement.
• Apprendre à utiliser les documents de conception de la solution.
• Examiner les rapports sur la réalisation du projet.
• Examiner les rapports d'état.
• Planifier et effectuer des activités de test au cours de différentes
phases.
• Organiser l'examen de passage.
• Préparer et diriger la transition de l'environnement hors production
à l'environnement de production.
Introduction
Les processus de réalisation et de suivi couvrent toutes les activités qu'un chef
de projet doit prendre en charge au cours des phases d'exécution d'un projet
visant à implémenter une solution Microsoft Dynamics® ERP.
Pour chaque projet, le chef de projet doit, en collaboration avec l'équipe projet,
identifier les activités et processus appropriés et déterminer dans quelle mesure
chaque activité doit être mise en œuvre.
La liste suivante répertorie les activités de gestion de projet des différentes

disciplines intervenant lors des phases d'exécution d'un projet, parmi lesquelles
la conception, le développement et le déploiement.
• Planification et exécution des tâches d'assurance qualité

• Planification et exécution du contrôle qualité
• Contrôle et clôture des achats et acquisitions
• Gestion permanente des risques
• Gestion permanente des problèmes
• Gestion du périmètre du projet
Supports de formation pour Microsoft Dynamics® 4-1

L’utilisation de ce contenu est réglementée par votre accord de service actuel.
Assurer la gestion de projet pour les implémentations de Microsoft…
• Gestion permanente du temps et des coûts

• Communication liée au projet
• Mise en place et gestion d'une équipe projet
Phase de conception
La phase de conception a pour objectif de définir le mode d'implémentation
des besoins métiers du client.
Elle inclut la configuration de la solution Microsoft Dynamics ERP globale,

la conception des personnalisations spécifiques qui sont nécessaires pour
répondre aux besoins métiers et la conception technique identifiée au cours
de la phase d'analyse.
FIGURE 4.1 CHRONOLOGIE DE LA PHASE DE CONCEPTION
4-2 Supports de formation pour Microsoft Dynamics®

Phase de développement
La phase de développement a pour objectif de créer et tester les composants
système définis et approuvés dans les spécifications de la conception. Elle inclut
le développement des personnalisations, intégrations et interfaces, ainsi que
des processus de migration des données.
FIGURE 4.2 CHRONOLOGIE DE LA PHASE DE DEVELOPPEMENT

Phase de déploiement
La phase de déploiement mobilise tous les efforts de l'équipe projet pour
garantir la réussite de la transition vers la nouvelle solution Microsoft
Dynamics ERP. Les principales activités de cette phase incluent la formation
des utilisateurs finaux, le test de performances et le test d'acceptation par
les utilisateurs, ainsi que la transition réelle vers le nouvel environnement
de production.
FIGURE 4.3 CHRONOLOGIE DE LA PHASE DE DEPLOIEMENT

Planification du projet
La planification de projet est une activité récurrente, mise en œuvre au cours
de toutes les phases du projet. Cela signifie que les phases de conception, de
développement et de déploiement incluront toutes une activité de planification.
L'objectif de la planification de projet au cours de ces phases consiste à analyser

et à suivre l'avancement du projet par rapport au plan, et à appliquer au plan
les ajustements nécessaires en fonction des modifications apportées au périmètre,
à la chronologie et aux ressources.
La planification du projet implique la mise à jour du plan de projet de façon

à représenter précisément la chronologie, les ressources et les jalons en tenant
compte des modifications apportées au périmètre.
La planification du projet dans le cadre de la phase de conception peut également

inclure la création d'un plan de déploiement en fonction du type de projet et des
spécifications propres à ce dernier. Le plan de déploiement décrit les activités
à mettre en œuvre pour faciliter le déploiement du système sur la base utilisatrice.
La planification du projet comprend également la mise à jour hebdomadaire des

données financières du projet afin de gérer son budget et de refléter fidèlement
son état financier.
Plan de déploiement
Le plan de déploiement décrit les activités à mettre en œuvre pour mener à bien
le déploiement de l'application sur la base utilisatrice.
Créé par le chef de projet, le plan de déploiement doit décrire les processus
et activités qui seront mis en œuvre lors de la phase de déploiement du projet.
Il est élaboré lors de la phase de conception de façon à laisser suffisamment

de temps à l'équipe projet pour l'étude des activités de déploiement. Il constitue
un document évolutif qui doit être constamment enrichi des commentaires
de l'équipe.
Ce plan répertorie toutes les tâches clés à exécuter pour mener à bien
le déploiement de l'application. Ces tâches incluent les suivantes :
• configuration de l'environnement ;
• migration des données ;
• paramétrage des utilisateurs ;
• formation des utilisateurs finaux.

Atelier 4.1.1 - Créer le plan de déploiement

L'objectif de cet atelier est de souligner que les activités de déploiement
doivent être étudiées dans les premières étapes du processus de planification.
Microsoft Dynamics® Sure Step recommande d'entreprendre ce processus lors
de la phase de conception de façon à laisser à chacun des membres de l'équipe
projet le temps nécessaire pour prendre en compte et traiter tous les aspects
requis du plan.
Scénario
La phase d'analyse est terminée et le lancement de la phase de conception est

en cours de planification. Les résultats de l'analyse approfondie effectuée par
Tailspin Toys ont été transmis et fournissent une vue précise des exigences de
la société quant à l'implémentation de Microsoft Dynamics ERP. À partir de ces
informations, vous avez élaboré un plan de projet général et reçu l'approbation
d'Adam Carter pour la mise en œuvre du projet.
La situation est assez complexe étant donné que la société Tailspin Toys est
implantée dans différentes zones géographiques et que l'implémentation implique
pratiquement tous les services ; le moment est donc venu de créer un plan plus
détaillé pour les phases de conception, de développement et de déploiement.
Nous sommes le 27 mai 2010 dans le cycle de vie du projet et celui-ci est
en cours de planification. Utilisez cet atelier pour examiner les activités
de déploiement à inclure dans votre plan de projet.
Description de l'objectif
Examinez les activités nécessaires pour la phase de déploiement et formalisez-les
dans le plan de déploiement.
Notez que le plan de déploiement est un document évolutif que vous

commencerez à mettre à jour dans cet atelier.

Étape par étape

Étape 1 - Répertorier toutes les activités de déploiement.
1. Quelles sont les activités de déploiement requises ? Répertoriez-les ici.
Étape 2 - Lire les informations importantes qui sont présentées ci-dessous.
La transition vers la mise en service doit s'effectuer le plus facilement possible.

Les réunions organisées à la fin de la phase d'analyse ont permis à Tailspin Toys
de définir des objectifs généraux concernant l'évolution ultérieure de
l'implémentation.
La société Tailspin Toys dispose de sites implantés dans différents pays et son
siège social est basé à Liverpool ; ce dernier gère de façon centralisée la plupart
des activités des sites. Seules les activités des entrepôts sont déléguées aux sites
de Boston et Hong Kong. Toutefois, ces différents sites sont reliés à distance via
le serveur central, qui se trouve au siège social de Tailspin Toys, à Liverpool.
Comme convenu, le service informatique interne de Tailspin Toys gérera

l'infrastructure ; par conséquent, vous-même ou les membres de votre équipe
ne serez pas obligés de vous rendre à Boston ou à Hong Kong.
Mike Nash sera entièrement responsable de la préparation des différents

environnements de production et hors production. Il validera les informations,
finalisera la planification des dates et heures d'installation, examinera
les procédures des utilisateurs et du personnel, et informera le service des
dates réelles des activités. Toutefois, au cours du processus d'installation
et de stabilisation, une aide sera fournie pour préparer le logiciel en vue de
l'installation, vérifier que la solution est opérationnelle pour les utilisateurs
et assurer un suivi régulier des défauts.

Tailspin Toys a décidé de procéder à l'arrêt du système hérité immédiatement

après l'installation de la solution Microsoft Dynamics ERP de façon que les
utilisateurs soient contraints de travailler avec la nouvelle application ERP.
Cette approche met l'accent sur la nécessité de mettre en œuvre des tests poussés
et des formations approfondies avant la mise en service. Tout au long de ce
processus, Trey Research se tiendra à la disposition de Tailspin Toys par le biais
des canaux de communication normaux qui ont été spécifiés au début du projet
dans le plan de communication.
Si la diversité des sites ne soulève aucune difficulté, la taille des différents

services s'avère problématique. L'équipe projet a été constituée. Toutefois,
les ressources disponibles sont limitées. Par conséquent, il reste peu de marge
pour la planification parallèle d'activités dites de suivi rapide. La traduction de
toutes les exigences en spécifications de conception et le développement du code
personnalisé pour tous les services à la fois risquant de prendre trop de temps,
Adam Carter a accepté de gérer le déploiement par service ou secteur d'activité.
Cela signifie que chaque membre de l'équipe de Tailspin Toys doit se charger
des activités de suivi, de test, d'acceptation et de signature pour son propre
service et son propre domaine de compétence. Avant la date réelle de mise en
service, ces mêmes personnes devront recevoir en temps voulu une formation
personnalisée sur les fonctionnalités standard et le code personnalisé. Il n'est
pas prévu que d'autres formations destinées aux utilisateurs finaux soient
dispensées par Trey Research ; en effet, les membres de l'équipe de Tailspin Toys
se chargeront eux-mêmes d'organiser ces formations une fois qu'ils auront assisté
aux sessions Formation des formateurs.
Membres
de l'équipe de Formation
Tailspin Toys Responsabilité requise
Adam Carter Vue d'ensemble
Mike Nash • Administration/Sécurité • Introduction -
• Intégration et interface 1 jour
• Migration des données • Sécurité -

1 jour
• (Infrastructure ; gérée
en interne)
Peter Houston • Finances, Gestion de la • Introduction -
trésorerie/Gestion des banques 1 jour
• Immobilisations, Comptes • Finances -
clients/fournisseurs 5 jours
• Création de rapports

Membres
de l'équipe de Formation
Tailspin Toys Responsabilité requise
Russell King • Commerce - Achats • Introduction -
• Stock/Logistique 1 jour
• Contrôle qualité • Commerce -

5 jours
• Création de rapports
• Contrôle
qualité –
1 jour
Shawn Richardson • Commerce - Ventes • Introduction -
• Stock/Logistique 1 jour
• Service clientèle • Commerce -

5 jours
• Création de rapports sur le
contrôle qualité • Contrôle
qualité –
1 jour
• Service
clientèle –
1 jour
Étape 3 - Localiser et ouvrir le plan de déploiement.
Examinez le contenu et la présentation du plan de déploiement disponible

dans Microsoft Dynamics Sure Step.
CONSEIL : vous trouverez l'activité et le modèle correspondant au plan

de déploiement dans la phase de conception des projets de type entreprise,
sous Planification du projet.

Étape 4 - Créer le plan de déploiement de Tailspin Toys.
Essayez de formaliser les informations fournies à l'étape 2 dans les sections

appropriées du plan de déploiement. Concentrez-vous sur les domaines qui
vous semblent les plus cruciaux pour le plan.
2. À quelles autres questions devez-vous répondre pour achever le plan

de déploiement ?

Atelier 4.1.2 - Mettre à jour le plan de projet

Cette activité a pour objectif de vérifier que le plan de projet incorpore les
dernières modifications apportées à la chronologie, aux ressources et aux jalons
en fonction des changements affectant le projet.
Scénario
Vous allez utiliser le même scénario que dans l'atelier 4.1.1.
Nous sommes le 27 mai 2010 et vous procédez à la planification du projet. Cette

tâche inclut non seulement la création du plan de déploiement, mais également la
mise à jour du plan de projet avec toutes les informations provenant de la phase
précédente et les données de planification spécifiques à la phase actuelle.
Tout changement affectant le projet peut avoir une incidence sur le plan
de projet. En tant que chef de projet, vous devez identifier ces changements
chaque semaine et les répercuter dans le plan de projet.
Étape par étape

Étape 1 - Identifier les changements ayant une incidence sur le plan
de projet.
1. Est-ce que des changements ont été identifiés au cours de la phase d'analyse ?
Si oui, quelle incidence ces événements ou changements auront-ils sur
le plan de projet ?

2. Examinez le plan de projet correspondant à un type de projet standard.

Quels éléments de la structure de répartition du travail doivent être
mis à jour pour mettre en œuvre le changement planifié ?
3. Quels autres événements peuvent nécessiter la mise à jour du plan de projet ?
Étape 2 - Examiner le plan de projet mis à jour.
Au cours du cycle de vie du projet (phases de conception, de développement

et de déploiement), le plan de projet de Tailspin Toys est continuellement
mis à jour. Ce plan de projet actualisé est mis à votre disposition.
4. À partir du plan de projet mis à jour, déterminez la durée de la phase

de conception.


de développement.

de déploiement.
7. Quelle est la durée entre le début du projet et la fin (planifiée) de la phase

de déploiement ?

8. Quelles phases et activités spécifiques sont liées à la remise des documents

de conception fonctionnelle (FDD, Functional Design Document) ?
Pour quelles dates ces activités sont-elles planifiées ?
9. Quelles activités incluent des tests et pour quelles dates sont-elles planifiées ?
10. Quelles tâches liées à la migration des données sont incluses dans
les différentes phases ? Quand sont-elles exécutées ?

11. Quelle est la date de mise en service fixée pour Tailspin Toys et au cours
de quelle phase cette opération est-elle réalisée ?

Conception de la solution
La phase de conception a pour objectif de définir le mode d'implémentation des
besoins métiers. Elle inclut la configuration de la solution Microsoft Dynamics
globale et la conception des personnalisations spécifiques qui sont nécessaires
pour répondre aux besoins métiers identifiés au cours de la phase d'analyse.
Les livrables de conception de la solution peuvent inclure les éléments suivants :
• Documents de conception fonctionnelle (FDD) des adéquations

(configurations)
• Documents de conception fonctionnelle (FDD) des écarts
(personnalisations)
o Documents de conception fonctionnelle des besoins identifiés
comme des écarts dans la solution standard
o Documents de conception fonctionnelle des besoins
en intégration et en interface
o Documents de conception fonctionnelle des exigences en matière
de migration des données
• Documents de conception technique (TDD)

• Document de conception de la solution (SDD)
Le chef de projet détermine les livrables de conception de la solution à utiliser

dans le projet en fonction du type de projet et des besoins.
Document de conception fonctionnelle

L'activité d'analyse des écarts aboutit à la génération de la matrice des écarts.
Cette matrice est utilisée pour déterminer les besoins métiers pouvant être
satisfaits à l'aide de la solution Microsoft Dynamics ERP ou de solutions
sectorielles, ou les écarts pouvant être résolus par le développement de code
personnalisé.
Consignation des adéquations dans le document de conception fonctionnelle

(FDD) Au cours de la phase de conception, le consultant applicatif collabore
étroitement avec l'utilisateur clé approprié. Ils documentent ensemble la
configuration et les paramètres requis pour permettre aux fonctionnalités
standard et aux solutions ISV de répondre intégralement aux besoins métiers.
Ces informations sont consignées dans le document de conception fonctionnelle.
Le modèle utilisé est appelé Document de conception fonctionnelle -

Configurations.

Dans ce modèle, documentez les informations suivantes :
• Vue d'ensemble de l'entreprise ;

• Besoins métiers ;
• Présentation de la solution ;
• installation et configuration ;
• Plan de test.
Consignation des écarts dans le document de conception fonctionnelle

(FDD) Le consultant applicatif et l'utilisateur clé approprié commencent
à documenter les besoins métiers qui seront satisfaits via le développement
de code personnalisé. Ces besoins sont appelés écarts. Ces informations
sont également consignées dans le document de conception fonctionnelle.
Le modèle utilisé est appelé Document de conception fonctionnelle -

Personnalisations.
Dans ce modèle, documentez les informations suivantes :
• Objectif de la modification ;
• À prendre en compte ;
• Modifications apportées aux formulaires ;
• Modifications apportées aux tables ;
• modifications apportées aux processus ;
• Autres modifications ;
• Gestion des erreurs ;
• Scripts de test.
Document de la conception technique

Les sections du document de conception fonctionnelle décrivant le
développement du code personnalisé servent ensuite de base à l'élaboration
du document de la conception technique (TDD, Technical Design Document).
Contrairement au document de conception fonctionnelle, le document de la
conception technique est impérativement créé par le consultant développement ;
il fournit des informations techniques détaillées qui sont nécessaires pour
entreprendre les tâches de développement.
Le Document de conception technique (TDD) vise à définir et documenter les

détails techniques de chaque modification ou amélioration apportée au système.
L'élaboration de documents de conception technique détaillés est essentielle
pour garantir l'exécution efficace des activités de développement ultérieures.
Ces documents servent de feuille de route pour le développement et reflètent la
conception fonctionnelle approuvée par le client en vue de son implémentation.

Document de conception de la solution

Le document de conception de la solution (SDD) vise à offrir aux décideurs
de l'entreprise et aux autres acteurs impliqués une vue précise de la solution
proposée. À ce titre, il fournit une description de la solution globale en langage
métier et présente les fonctions que cette dernière prend en charge.
Flux d'informations entre le document des besoins

fonctionnels et les documents de conception
Le graphique ci-dessous, qui illustre le flux d'informations entre le document
des besoins fonctionnels et les documents de conception, se trouve dans le nœud
Ressources supplémentaires de Microsoft Dynamics Sure Step.
FIGURE 4.4 FLUX D'INFORMATIONS ENTRE LE DOCUMENT DES BESOINS

FONCTIONNELS ET LES DOCUMENTS DE CONCEPTION

En qualité de chef de projet, identifiez les documents de conception qui doivent

être implémentés pour votre projet. Microsoft Dynamics Sure Step suggèrera
les documents à utiliser en fonction du type de projet sélectionné.
Différentes options sont possibles, y compris les suivantes :
• implémentation de l'ensemble complet de documents de conception ;

• implémentation de documents spécifiques uniquement ;
• implémentation des documents de conception fonctionnelle
et de conception technique pour chaque ÉCART et chaque
ADÉQUATION ;
• implémentation de différentes combinaisons de ces documents.

Atelier 4.2.1 - Représenter les adéquations dans le document

de conception fonctionnelle
Au cours de cet atelier, vous apprendrez à documenter la configuration et
les paramètres requis pour permettre aux fonctionnalités standard et aux
solutions ISV de répondre intégralement aux besoins métiers.
Scénario
La représentation des adéquations et le processus de configuration système

standard sont mis en œuvre le 1er juin 2010. À cette date, les environnements
hors production requis sont configurés. Brian Burke et Jim Wilson font partie
de l'équipe de Trey Research qui est chargée de la conception de la solution.
Ils collaboreront étroitement avec les utilisateurs clés de Tailspin Toys.
Il a été convenu que l'équipe documenterait les adéquations et les écarts dans
les différents documents de conception fonctionnelle. En outre, l'ensemble
des adéquations et écarts seront consignés dans un document de conception
fonctionnelle séparé.
L'objectif de cet atelier est d'examiner le modèle Document de conception
fonctionnelle - Configuration. Dans ce modèle, les adéquations identifiées
pour Tailspin Toys sont déjà configurées.
Étape par étape

Étape 1 - Localiser le document de conception fonctionnelle
de la configuration de Tailspin Toys et examiner son contenu.
1. Combien de besoins sont pris en charge dans ce document de conception

fonctionnelle ?

2. Quel besoin est traité dans ce document de conception fonctionnelle ?
3. Quelle solution est choisie pour ce besoin spécifique ?

Atelier 4.2.2 - Représenter les écarts dans le document

Différents écarts ont été identifiés au cours des phases de diagnostic et
d'analyse. Ils sont gérés par Brian Burke, Jim Wilson et les utilisateurs clés
de Tailspin Toys.
Scénario
Nous sommes à présent le 24 juin 2010 et, en qualité de chef de projet, vous
devez examiner le document de conception fonctionnelle de la personnalisation.
Brian Burke et Jim Wilson ont documenté leurs conclusions concernant
les écarts dans le document de conception fonctionnelle de la personnalisation.
Vous souhaitez examiner ce document de conception et étudier son contenu.
Étape par étape

Étape 1 - Localiser le Document de conception fonctionnelle-
Personnalisations de Tailspin Toys et examiner son contenu.
1. Décrivez le contenu de ce document. Quel besoin ce document traite-t-il ?

2. La conception proposée répond-elle aux besoins fonctionnels ?
3. Le document inclut une présentation de la solution. La présentation proposée

convient-elle au client ? Pourquoi cette condition est-elle nécessaire ?

Atelier 4.2.3 - Créer un document de conception

de la solution
Ce document fournit une description de la solution globale en langage métier
et présente les fonctions que cette dernière prend en charge.
Scénario
Le 9 juillet 2010, Brian Burke commence à créer le document de conception

de la solution. L'équipe a travaillé à l'élaboration de différents documents de
conception pendant le mois de juin. Plusieurs documents de ce type ont ainsi
été créés.
Pour obtenir une vue précise de la solution proposée, le chef de projet

a recommandé de créer un document de conception de la solution.
L'objectif de cet atelier est d'étudier le contenu du document de conception
de la solution et de découvrir l'utilité de ce dernier.
Étape par étape

Étape 1 - Localiser le modèle Document de conception de la solution
dans Microsoft Dynamics Sure Step et examiner son contenu.
1. Indiquez pourquoi un document de conception de la solution doit être utilisé

dans le projet.

2. Quelles informations doivent figurer dans le document de conception

de la solution (SDD) ?
3. Examinez le modèle de document SDD. Répertoriez les différentes sections

de ce dernier.
4. La section 4 (Stratégie et concept de la solution) du document SDD contient

différentes sous-sections. Quel type d'informations figure dans cette section ?

5. Le chef de projet peut choisir les documents de conception à utiliser

et définir le contenu devant figurer dans ces derniers. Décrivez le
contenu de la section Architecture de la solution du document SDD.
CONSEIL : examinez le modèle Document de conception de la solution

et l'exemple de document de conception de la solution disponibles dans
Microsoft Dynamics Sure Step pour comprendre dans quelle mesure
les besoins liés au projet déterminent le contenu du document SDD.
6. Préparez-vous à participer à la discussion collective à venir. Identifiez les

documents de conception qui vous semblent les plus importants et les types
de projets susceptibles de les utiliser.

Atelier 4.2.4 - Utilisation des documents de conception

Les différents documents de conception ayant été examinés, il est maintenant
temps d'analyser les conclusions qui en découlent.
Scénario
Les sujets abordés dans le cadre de cette discussion incluent les suivants :
• Quels avantages présente l'utilisation des documents de conception ?

Pour quels types de projets ces documents peuvent-ils être utiles ?
• Quel est votre point de vue sur l'utilisation de documents de
conception séparés pour chaque écart et chaque adéquation ?
• Donnez votre avis sur le document de conception de la solution.
Quelle est l'utilité du document SDD pour l'équipe projet ?
• Comment est évalué le contenu du document SDD
de Tailspin Toys ?

Création de rapports sur l'état et la réalisation du projet

Les rapports sur l'état et la réalisation du projet sont des éléments essentiels de
la gestion de la communication liée au projet. La gestion de la communication
représente un facteur de réussite déterminant pour tout projet. Cette activité doit
être assurée en permanence, tout au long de la réalisation du projet, de façon
à satisfaire les besoins des acteurs impliqués. Selon le type de projet et les
besoins associés, différentes tâches peuvent être exécutées dans le cadre
de cette discipline.
Création de rapports sur la réalisation du projet

Les rapports sur la réalisation du projet permettent de recueillir et
de communiquer des informations sur les performances. Ces informations
incluent les rapports d'état, l'évaluation de l'avancement et les prévisions.
Le processus de création de rapports sur la réalisation du projet comprend

la collecte de toutes les données de base et la transmission des informations
relatives aux performances aux acteurs impliqués. En règle générale, ces
informations décrivent entre autres la façon dont les ressources sont utilisées
pour atteindre les objectifs du projet. Les rapports fournissent habituellement
des informations sur le périmètre, l'agenda, le coût et la qualité du projet.
De nombreux projets requièrent également des données sur les risques et
l'approvisionnement.
Un processus de création de rapports approprié offre notamment

les avantages suivants :
• état précis et actualisé du projet ;

• données fiables permettant d'apporter des corrections de manière
proactive ;
• gestion des attentes des acteurs impliqués du projet ;
• référence historique pour les estimations futures ;
• aucune surprise à craindre pour le client ;
• représentation plus précise des tâches à réaliser dans les délais
impartis.
Création de rapports d'état du projet

La création de rapports d'état du projet fournit au client un récapitulatif
hebdomadaire du projet reprenant les réalisations, les décisions, le travail
planifié, les risques et les problèmes.
Un rapport d'état est un document établi chaque semaine par le responsable

de programme à l'aide des informations fournies par les rapports d'état
des consultants et le plan de projet actualisé.

Il contient les informations suivantes :
• l'état général du projet ;

• les tâches réalisées au cours de la semaine ;
• les décisions prises ;
• les tâches prévues pour la semaine suivante ;
• les problèmes et les risques ;
• la planification des vacances ;
• les heures prévues/réelles communiquées par le consultant.
Le rapport d'état est d'abord examiné par l'équipe projet lors d'une réunion
d'avancement hebdomadaire interne, puis présenté au client selon l'agenda
convenu.

Atelier 4.3.1 - Examiner le rapport d'état du consultant

Au cours de cet atelier, vous allez examiner un rapport d'état du consultant.
Ce document est créé lors de la phase de développement.
Scénario
L'activité de développement a commencé le 23 juillet 2010 et doit se terminer

le 3 septembre 2010. La charge de travail à accomplir inclut les tâches suivantes :
• codage personnalisé ;
• migration des données ;
• intégration et interfaces.
La planification peut être examinée selon la chronologie indiquée au

début de ce chapitre et dans le plan de projet. Les estimations du temps de
développement sont documentées dans le fichier Microsoft® Office Excel®
Estimation du développement.
L'objectif de cet atelier est d'examiner un rapport d'état du consultant prenant en
charge le développement du code personnalisé pour Tailspin Toys. Votre travail
va consister à passer en revue ce document.
Étape par étape

Étape 1 - Localiser le document Estimation du développement créé
pour Tailspin Toys et examiner son contenu.
1. Quels consultants interviennent lors du codage personnalisé ?

2. Combien de jours sont estimés nécessaires pour l'achèvement

de la fonctionnalité Commerce ?
Étape 2 - Localiser l'état Rapport d'état du consultant créé pour

Tailspin Toys et examiner son contenu.
3. Quel consultant a réalisé un rapport d'état de ses propres tâches et quelle

est la période prise en compte dans ce document ?
4. Quel travail a été accompli par le consultant au cours de cette période ?

5. Quelles réalisations Jim Wilson planifie-t-il pour la période suivante ?
6. Que pensez-vous du rapport d'état de Jim Wilson du point de vue

de la gestion de projet ?

Atelier 4.3.2 - Créer le rapport d'état du projet

Les rapports d'état du projet fournissent au client un récapitulatif hebdomadaire
indiquant les réalisations, les décisions, le travail planifié, ainsi que les risques
et les problèmes identifiés. L'objectif de cet atelier est de créer un rapport d'état
du projet.
Scénario
Nous sommes vendredi 4 septembre 2010. Tous les consultants ont transmis
leur rapport d'état pour la semaine. Jim Wilson et Diane Prescott ont signalé
qu'ils travaillaient toujours sur l'activité QC-2/5. Le démarrage des tâches
qui leur incombent ayant été différé, ils ont pris du retard. Par ailleurs, la
spécification de besoins inappropriés dans les documents de conception leur
a posé des problèmes. Ils ont déterminé que la vision initiale de la solution ne
correspondait pas aux attentes actuelles des utilisateurs clés après avoir discuté
avec ces derniers.
Par conséquent, le développement du code personnalisé pour les activités

Création de rapports et Finances n'a pas encore commencé.
Josh Pollock a signalé qu'il avait achevé le développement de la migration

des données pour les adéquations et travaillait maintenant sur la migration
des données en rapport avec les écarts. Toutefois, pour qu'il puisse terminer
son travail, la fonctionnalité requise pour QC-2/5 doit avoir été finalisée par
Jim Wilson et Diane Prescott.
Heather Murchison a signalé le 3 août 2010 qu'elle avait terminé

le développement de l'intégration et des interfaces.
Créez un rapport d'état du projet pour cette période à l'aide du modèle fourni
dans Microsoft Dynamics Sure Step.

Étape par étape

Étape 1 - Localiser le rapport d'état du projet dans Microsoft Dynamics
Sure Step.
Complétez le rapport à l'aide des informations fournies dans le scénario.
1. Quelles informations essentielles avez-vous choisi de communiquer dans

le rapport d'état du projet ?

Test
Les tests permettent de garantir que le projet est conforme aux normes de
qualité afin de dépasser les objectifs de satisfaction du client. On ne soulignera
jamais assez la valeur de tests complets, correctement maîtrisés. Même lorsque
les personnalisations sont limitées, il est important que le client exécute ses
processus métiers types dans le nouvel environnement afin de vérifier que
les procédures de workflow des utilisateurs et les paramètres de configuration
de l'application garantissent une productivité optimale.
Les types de tests à exécuter et leur périmètre dépendent du type de projet

et des besoins associés.
Tests dans le cadre d'une phase croisée

Les activités de test peuvent être mises en œuvre au cours de différentes phases
du cycle de vie du projet. Bien que les activités de création, de mise à jour
ou d'exécution des scripts de test soient traitées dans les phases de conception,
de développement et de déploiement, il est important de prendre en compte
les activités de test lors de la définition du périmètre et du travail de planification
qui ont lieu dans le cadre de la phase d'analyse. La planification des tests est
effectuée lors de la phase d'analyse afin de mettre en place un plan global de
test et d'établir les normes et procédures générales à suivre lors des tests et de
la validation du logiciel. Au fur et à mesure de l'avancement du projet, le plan
de projet doit être mis à jour en fonction des activités liées aux tests.
Au cours de la conception, mais plus particulièrement lors des phases

de développement et de déploiement, les activités de configuration, de
personnalisation et de migration des données requièrent la création d'un
processus de gestion des modifications/versions du système dans le cadre
de la phase d'analyse. Ce processus détaille les environnements à conserver,
les méthodes à utiliser pour répercuter les modifications apportées à un
environnement de développement et/ou de test dans un environnement de
production, ainsi que l'ensemble des tests et approbations nécessaires tout
au long de ce dispositif.
Les activités de contrôle de la qualité et de test s'étendent de l'implémentation

et du déploiement de la solution Microsoft Dynamics jusqu'à la phase
d'exploitation.
Les activités de clôture de l'implémentation incluent l'évaluation des livrables

et des critères d'acceptation par rapport à l'énoncé des travaux et aux ordres de
modification ; cette tâche vise à s'assurer que toutes les obligations contractuelles
sont respectées. Toute la documentation doit être mise à jour, vérifiée, finalisée
et préparée pour être remise au client.

Activités de test lors de la phase de conception

Les activités de test suivantes peuvent être mises en œuvre au cours de la phase
de conception :
• exécution du test des fonctionnalités des solutions standard et ISV,

évaluation des résultats et application des ajustements nécessaires
à la configuration ;
• création de scripts de tests unitaire et fonctionnel pour le code
personnalisé ;
• création de scripts de test d'intégration ;
• création de scripts de test pour la migration des données ;
• identification des scénarios de test des processus ;
• création d'un sous-ensemble de données pour les tests.
Activités de test lors de la phase de développement

Les activités de test suivantes peuvent être mises en œuvre au cours de la phase
de développement :
• Test des sous-processus : test des fonctionnalités associées à un

processus métier défini. Il est réalisé au cours de la configuration
par le client et les consultants applicatifs.
• Test unitaire : test autonome des modifications du système
(code personnalisé). Il est réalisé lors de la phase de développement
par les consultants développement.
• Test des fonctions : test autonome des modifications du système
(code personnalisé). Il est réalisé lors de la phase de développement
par le client et les consultants.
• Test des processus : test complet des fonctionnalités et fonctions
associées à un processus métier défini. Il est réalisé lors de la phase
de développement par le client et les consultants.
• Test d'intégration : test d'intégration des processus métiers.
Il est réalisé par les utilisateurs clés avant l'acceptation (signature)
du système. L'accent est mis sur les processus métiers de bout en
bout, et notamment sur le développement, les interfaces, les rapports
et les intégrations aux systèmes externes.
• Test d'acceptation des données (DAT, Data Acceptance Testing) :
test réalisé par les propriétaires des données et les utilisateurs clés
au cours de la phase de développement, avant le test d'intégration.
Au cours de ce test, le client non seulement vérifie les données
migrées, mais s'assure également qu'elles peuvent faire l'objet
de requêtes, de rapports et de transactions.

• Développement des scripts de test de performances :

test des processus métiers et de l'intégration. Ce test s'applique
principalement aux volumes élevés de transactions qui sont attendus
aux heures de pointe. Il vise à vérifier que les performances système
sont en adéquation avec les besoins métiers. Il est réalisé par l'équipe
chargée du projet d'implémentation, généralement à l'aide d'un
logiciel d'automatisation de tests.
• Développement des scripts de test d'acceptation par les
utilisateurs (UAT) : test final réalisé par les utilisateurs clés avant
l'acceptation (signature) du système. Les utilisateurs finaux qui ont
été sélectionnés pour réaliser ce test doivent avoir reçu préalablement
une formation appropriée.
Activités de test lors de la phase de déploiement

Les tests effectués pendant la phase de déploiement visent notamment à s'assurer
que le système configuré sous charge satisfait aux mesures de performances ;
ils doivent également permettre de vérifier que l'installation et la configuration
globales répondent aux besoins métiers du client et conduisent à la signature
d'acceptation par les utilisateurs.
• Le test de performances permet de vérifier les processus métiers

et l'intégration, et s'applique principalement aux volumes élevés
de transactions qui sont attendus aux heures de pointe. Il vise
à vérifier que les performances système sont en adéquation avec
les besoins métiers.
• Test d'acceptation par les utilisateurs : test final réalisé par
les utilisateurs clés avant l'acceptation (signature) du système.
Les utilisateurs finaux qui ont été sélectionnés pour réaliser ce
test doivent avoir reçu préalablement une formation appropriée.
Environnements de test
La conception, la planification et la création des environnements hors production
au cours de la phase de conception incluent la mise en place d'environnements
de test pour l'exécution des scripts et scénarios de test suivants :
• test unitaire et fonctionnel ;

• test des processus ;
• test d'intégration ;
• test de la migration des données ;
• test de performances ;
• test d'acceptation par les utilisateurs.
Ces scripts de test sont exécutés lors des phases de développement et de

déploiement. Selon la complexité de l'engagement, des environnements séparés
peuvent s'avérer nécessaires pour le test de performances et le test d'acceptation
par les utilisateurs (UAT).

Atelier 4.4.1 - Test unitaire et fonctionnel

Au cours de cet atelier, vous allez effectuer le suivi de toutes les activités liées
aux tests du code personnalisé, également appelés test unitaire et fonctionnel.
Scénario
Outre le document de la conception technique, les consultants développement

Jim Wilson, Josh Pollock et Diane Prescott ont créé divers scripts de test pour
répondre aux différents besoins en code personnalisé au cours de la période allant
du 29 juin au 7 juillet 2010.
Au cours de la phase de développement, ces tests ont été réalisés par les
consultants développement et les utilisateurs clés de Tailspin Toys. Les tâches
de développement et de test du code personnalisé ont été mises en œuvre du 23
juin au 3 septembre 2010.
Les résultats des tests sont analysés le 4 septembre 2010 pour faire suite aux
rapports d'état des consultants (voir la leçon et les ateliers précédents).
En tant que chef de projet, effectuez le suivi des tâches liées à la création
des scripts de test en vous appuyant sur les résultats obtenus lors du test
de performances.
Étape par étape

Étape 1 - Examiner les scénarios de script de test.
Localisez le Modèle de scénario de test fonctionnel/unitaire utilisé pour

Tailspin Toys et examinez les scripts de test créés.
CONSEIL : bien que cet atelier fasse appel au modèle de script de test
fonctionnel/unitaire pour Microsoft Dynamics AX, il est recommandé de prendre
quelques minutes pour examiner les autres modèles disponibles pour cette
activité dans Sure Step.

1. Indiquez les domaines fonctionnels pour lesquels aucun script de test

n'a été créé. Pour quelle raison ?
2. Pour quels domaines fonctionnels ces scripts de test sont-ils créés ?
3. Les scripts de test créés sont-ils suffisants ? Quel document permet

de vérifier ce point ?

Étape 2 - Examiner les résultats des tests dans la matrice du scénario

de test unitaire et fonctionnel qui a été mise à jour.
4. Qui est chargé d'exécuter les tests unitaires et fonctionnels ?
5. Dans quel document les résultats des tests sont-ils examinés ? Localisez
ce document et ouvrez-le afin de l'examiner.
6. Les résultats obtenus pour certains domaines fonctionnels sont-ils

problématiques ? Si oui, quels sont ces domaines et quel est l'impact
des problèmes rencontrés ?

7. Examinez le document Modèle de script de test fonctionnel et unitaire

disponible dans Microsoft Dynamics Sure Step. En quoi diffère-t-il du
Modèle de script de test fonctionnel/unitaire examiné précédemment ?
Utiliserez-vous systématiquement les deux documents ?

Atelier 4.4.2 - Test d'acceptation par les utilisateurs

Au cours de cet atelier, vous allez superviser les activités de test avant
d'entreprendre le processus d'acceptation du système par le client de façon
à vous préparer, conjointement avec l'équipe projet, aux activités de mise
en service.
Scénario
Au cours de la phase de développement (du 7 au 25 septembre 2010), différents

scripts de test d'acceptation par les utilisateurs ont été compilés conformément
aux conditions de satisfaction établies pendant la phase d'analyse.
Les données requises du test d'acceptation par les utilisateurs ont été migrées
dans l'environnement de transit le 21 octobre 2010, de façon qu'il soit prêt pour
l'exécution des tests. Les utilisateurs ont effectué les tests sur une période
d'une semaine (du 22 au 28 octobre 2010).
En tant que chef de projet, vous êtes chargé de la planification des tests
d'acceptation par les utilisateurs et de leur mise en place dans les délais impartis.
Lors de ces tests, contrôlez précisément les résultats, car ils peuvent avoir
un impact sur l'agenda global du projet.
Étape par étape

Étape 1 - Examiner les scénarios de script de test et les résultats des tests.
Localisez le modèle de scénario de test d'acceptation par les utilisateurs utilisé

pour Tailspin Toys et examinez les résultats.
1. Selon quel principe le modèle est-il divisé ?

2. Qui est chargé d'exécuter les tests d'acceptation par les utilisateurs ?
3. Dans quel environnement est-il préférable d'exécuter le test d'acceptation

par les utilisateurs ? Quand cet environnement a-t-il été configuré ?


Étape 2 - Étapes suivantes
Selon les résultats des tests, préparez-vous à poursuivre le cycle de vie du projet.
5. Tous les tests ayant été effectués, quelles sont les étapes suivantes logiques
du projet de Tailspin Toys ?
6. Compte tenu des résultats des tests d'acceptation par les utilisateurs,
pensez-vous que la société Tailspin Toys est prête à signer l'acceptation
du système complet ?
7. Pensez-vous que, si tous les tests avaient réussi, l'étape finale du projet
aurait-pu être automatiquement atteinte ?

Examen de passage
L'examen de passage peut avoir lieu à la fin de chaque phase du cycle de
vie du projet. Il représente un facteur de qualité du projet et un passage obligé
conditionnant, à la fin de chaque phase, le passage à la phase suivante. Tous les
projets ne font pas appel aux examens de passage. Il incombe au chef de projet
et à l'équipe projet de définir les normes régissant le passage d'une phase à l'autre.
La tendance consistant à passer rapidement d'une phase à l'autre pour soutenir

la progression de l'équipe remet fréquemment en question les normes initialement
définies pour l'achèvement d'une phase particulière. On considère souvent qu'il
est possible d'obtenir les livrables manquants en exécutant des tâches en parallèle
ou en demandant à l'équipe d'effectuer quelques heures supplémentaires.
Toutefois, les interdépendances entre les activités finissent par créer des goulots
d'étranglement lorsque de nombreuses activités dépendent d'une tâche qui n'a pas
été achevée au cours d'une phase précédente. Le projet entier s'enlise suite à des
problèmes répétés de non-respect des livrables et des retards qui se multiplient
de façon exponentielle.
La présentation de l'examen de passage est préparée par le chef de projet.

Le client assistera à celle-ci à la fin de la phase ; l'équipe projet principale sera
également présente. L'équipe projet principale est composée des responsables
du projet, du commanditaire et des utilisateurs clés. L'examen de passage met
l'accent sur l'état actuel du projet, les principaux jalons atteints, les livrables clés
qui ont été achevés, les problèmes et risques liés au projet, ainsi que l'évaluation
des conditions de satisfaction.
Il vise à s'assurer que l'équipe projet est en phase avec la progression du projet et
qu'elle met en place un plan d'action pour faire face aux problèmes et risques liés
à la phase suivante.

Atelier 4.5.1 - Préparer l'examen de passage

Au cours de cet atelier, vous allez créer un rapport d'examen de passage.
Scénario
L'examen de passage aura lieu dans les locaux de Tailspin Toys le 30 septembre
2010. Nous sommes maintenant le 29 septembre 2010 et vous devez préparer
cet examen.
Les rapports d'état du projet créés lors de la phase de développement ont révélé
un dépassement des délais et du budget. En chef de projet proactif, vous avez
implémenté des actions correctives qui impliquaient l'intervention d'un consultant
développement externe. Vous avez pu ainsi gérer le dépassement de délai,
mais n'êtes pas parvenu à éviter le dépassement de budget.
Le 25 septembre 2010, votre équipe a signalé les points suivants :
• Le développement de l'intégralité du code personnalisé est terminé.

• Toutes les tâches de développement en matière d'intégration
et d'interface sont terminées.
• Le développement lié à la migration des données est terminé.
• Les documents de conception sont mis à jour.
• Le test d'intégration est terminé.
• Le test d'acceptation par les utilisateurs est terminé.
• Le test unitaire a été effectué.
• Le test des fonctions a été effectué.
La feuille de calcul des chiffres réels du développement récapitule les valeurs

réelles enregistrées pour chaque livrable lors de la phase de développement.
Les conversations engagées avec les membres de l'équipe de développement

révèlent que le dépassement est dû à plusieurs raisons, parmi lesquelles :
• des zones d'ombre dans la conception causées par des zones d'ombre
dans l'analyse ;
• les changements d'avis des utilisateurs clés concernant la solution
attendue ;
• la sous-estimation des rapports analytiques.
Il semble par ailleurs que lors de la phase de développement, la communication

entre les deux équipes ne se soit pas établie aussi bien que prévu. Les utilisateurs
clés prétendent qu'ils n'ont pas reçu d'informations, tandis que les membres de
l'équipe de développement n'ont obtenu que des commentaires incomplets
de la part de l'équipe des utilisateurs clés. Toutefois, vous être convaincu
que le niveau de qualité fourni pour le code personnalisé et la configuration
répond aux attentes.

Nous sommes le 29 septembre 2010 et le moment est venu de créer le rapport
d'examen de passage pour clôturer la phase de développement.
Étape par étape

Étape 1 - Localiser le modèle de rapport d'examen de passage dans
Microsoft Dynamics Sure Step.
Concentrez-vous sur les informations essentielles pour réaliser le rapport

d'examen de passage dans le cadre de la préparation de cet examen. Soyez
prêt à présenter votre approche aux autres participants.

Mise en service
L'activité de mise en service se termine à la fin de la phase de déploiement.
Elle vise à lancer un processus de traitement efficace des transactions et activités
métiers quotidiennes dans le nouveau système.
L'environnement de production est installé et configuré. Les fonctionnalités

et les performances ont été validées et acceptées (signées) à la fin des activités
de test. Le plan de transition a été vérifié et testé de façon très approfondie.
La migration finale des données a été achevée et validée lors des étapes
antérieures. Enfin, la formation des utilisateurs finaux a été dispensée et ces
derniers maîtrisent parfaitement les tâches quotidiennes qu'ils doivent exécuter
dans le nouveau système.
Le système est désormais prêt à traiter les transactions requises et à exécuter

les processus métiers tels qu'ils ont été définis lors des ateliers sur les besoins
métiers. Après la transition vers le nouveau système, les utilisateurs finaux auront
peut-être besoin d'une aide supplémentaire ; l'équipe d'implémentation doit être
capable de continuer à les guider au cours de la phase d'apprentissage initiale.
Plan de transition vers la mise en service

L'objectif de cette activité est de garantir la mise en place d'un processus de
transition planifié, documenté et testé. Elle réduit les risques d'erreur au cours
de la période de mise en service, lesquels peuvent avoir un impact important
sur l'acceptation par les utilisateurs et sur la solution dans son ensemble.
Lors de la planification de la transition vers la mise en service, tenez compte

des éléments clés suivants :
• Plan : élaborez un plan de transition vers la mise en service

présentant tous les participants impliqués dans le projet et
les principales activités.
• Document : rédigez un document décrivant le processus
de transition vers la mise en service et détaillant étape par étape
le plan ci-dessus. Incluez toutes les décisions clés et un plan
de retrait détaillé à mettre en œuvre en cas de problème.
• Test : il est recommandé d'exécuter intégralement le processus de
transition en tant que « répétition préliminaire » dans l'un des autres
environnements, au moins deux semaines avant la date prévue pour
la transition finale. Dans le cas de projets complexes, vous devrez
peut-être faire appel à plusieurs itérations de test et apporter des
améliorations au processus de transition.

Atelier 4.6.1 - Créer un plan de transition vers la mise

en service
Examinez les éléments à préparer et les tâches à exécuter avant la mise
en service.
Scénario
La mise en service dans les locaux de Tailspin Toys est prévue pour
le 9 novembre 2010.
Elle sera effectuée service par service de façon que chaque département bénéficie
d'une attention suffisante. Une fois la solution Microsoft Dynamics ERP
installée, le système hérité sera immédiatement arrêté de façon que les
utilisateurs soient contraints de travailler avec le nouvel environnement ERP.
Adam Carter continue à penser qu'il s'agit de la pratique la plus appropriée
pour sa société.
Toutefois, avant l'installation de ces environnements de production, un travail

important de préparation et de planification reste à effectuer. La plupart de ces
tâches incombent au responsable informatique de Tailspin Toys, Mike Nash,
qui est chargé d'installer l'infrastructure de la société. Il sera néanmoins assisté
si nécessaire par le consultant technologie de Trey Research, Heather Murchison.
Les tâches effectuées avant l'installation de l'environnement de production

incluent les suivantes :
• Développement de l'intégralité du code personnalisé : 03/09/2010

• Réalisation et acceptation de tous les ajustements nécessaires :
18/09/2010
• Exécution du test d'acceptation par les utilisateurs : 28/10/2010
• Mises à niveau de l'infrastructure : 06/11/2010
• Formation des utilisateurs clés et des utilisateurs finaux : 06/11/2010
L'environnement de transit a été pollué et altéré lors du test de performances.

L'environnement de production a par conséquent dû être créé à partir
d'une version antérieure de la base de données et sauvegardé avant le test.
Heather Murchison fournira une telle version à Mike Nash étant donné qu'elle est
responsable de la sauvegarde de la base de données avant chaque modification.
Par ailleurs, au cours de la mise en service, Heather Murchison sauvegardera
régulièrement le contenu du système. En cas d'urgence, elle pourra procéder
à une restauration à partir de la dernière sauvegarde. Ce processus sera lancé
par le consultant applicatif Brian Burke qui en informera tous les membres
du projet concernés.

Différents utilisateurs devront être configurés pour l'environnement de

production. Brian Burke sera chargé de cette tâche et de la migration des
données requises depuis le système hérité vers l'environnement de production.
Ce travail commencera une semaine avant la date réelle de la mise en service.
Les utilisateurs clés et les utilisateurs finaux recevront une formation complète
avant la mise en service ; Adam Carter est néanmoins soucieux de faciliter la
tâche de ses employés. Ceux-ci doivent pouvoir être aidés en cas de problème
et supervisés si nécessaire. Bien qu'il soit impossible de mobiliser à plein
temps au siège social de Tailspin Toys un des membres du projet affectés
par Trey Research, un compromis est obtenu et une réunion de contrôle
hebdomadaire est prévue pour rendre compte de la progression des utilisateurs
finaux. Les deux chefs de projet, Adam Carter et vous-même, participeront
à cette réunion.
L'objectif de cet atelier est de préparer la transition de l'environnement hors
production à l'environnement de production. En tant que chef de projet, vous
devez être bien organisé et veiller à ce que la mise en service s'effectue le plus
facilement possible car elle constitue le dernier jalon avant la phase d'exploitation
et la clôture (réussie) du projet.
Étape par étape

Étape 1 - Préparer la transition vers la mise en service.
1. Dans votre plan de projet, examinez l'activité planifiée pour la mise en

service. Combien de jours sont planifiés pour la mise en service ? Est-ce
réaliste compte tenu de l'approche définie dans le plan de transition vers
la mise en service ? Pourquoi ?

2. Quel est l'impact de votre décision précédente ?
3. Est-ce que certains sites requièrent un accès distant à la solution Microsoft

Dynamics ERP ? Si oui, quels services nécessitent ce type d'accès et qui
est chargé de le configurer ?
4. Au cours de quelles activités précédentes les rôles de sécurité sont-ils

définis ? Brian Burke aura besoin de cette information pour créer
les différents utilisateurs dans l'environnement de production.

Étape 2 - Créer le plan de transition vers la mise en service.
À partir du scénario de l'atelier et des questions de l'étape précédente,

établissez le plan de transition vers la mise en service à l'aide du modèle
fourni dans Microsoft Dynamics Sure Step pour Microsoft Dynamics AX.
Concentrez-vous sur les domaines qui vous semblent essentiels pour

la réussite de la mise en service et préparez-vous à présenter vos choix
aux autres participants.
Pour obtenir des conseils supplémentaires, reportez-vous à l'activité de mise

en service dans Sure Step et à la liste de contrôle associée.

Résumé
Ce chapitre traite des activités clés de gestion de projet mises en œuvre lors des
phases de conception, de développement et de déploiement. Plusieurs activités
sont présentées dans ce chapitre, y compris les suivantes :
• Création d'un plan de transition vers la mise en service.

• Utilisation des documents de conception de la solution.
• Étude des rapports sur l'état et la réalisation du projet.
Ce chapitre traite également de l'étude, de la planification et de la coordination

des activités de test, ainsi que de l'organisation d'un examen de passage.

Révision rapide : retours d'expériences

Inscrivez ci-dessous les trois éléments clés que vous avez appris dans ce chapitre
1.
2.
3.

Solutions
Atelier 4.1.1 - Créer le plan de déploiement
1. Quelles sont les activités de déploiement requises ? Répertoriez-les ici.
RÉPONSE TYPE : Formulez votre réponse en vous appuyant sur votre
expérience de l'implémentation et sur les spécifications de Tailspin Toys.
Il n'y a pas de réponse incorrecte
2. À quelles autres questions devez-vous répondre pour achever le plan

de déploiement ?
RÉPONSE TYPE : Formulez votre réponse en vous appuyant sur votre
expérience de l'implémentation et sur les spécifications de Tailspin Toys.
Il n'y a pas de réponse incorrecte
Atelier 4.1.2 - Mettre à jour le plan de projet

1. Est-ce que des changements ont été identifiés au cours de la phase d'analyse ?
Si oui, quelle incidence ces événements ou changements auront-ils sur le
plan de projet ?
RÉPONSE TYPE : Oui, des changements ont été identifiés au cours de
la phase d'analyse. Un seul de ces changements est approuvé par le client ;
il consiste à implémenter Microsoft Dynamics® CRM pour répondre
aux exigences de service clientèle concernant le suivi des réclamations.
Par conséquent, les exigences relatives à l'enregistrement des réclamations
sont désormais hors du périmètre de l'implémentation de la solution
Microsoft Dynamics ERP. Ce changement affecte les phases de conception
et de développement avec une réduction du nombre de jours (-5 jours)

2. Examinez le plan de projet correspondant à un type de projet standard.

Quels éléments de la structure de répartition du travail doivent être mis
à jour pour mettre en œuvre le changement planifié ?
RÉPONSE TYPE : Le changement approuvé réduit le périmètre de
l'implémentation en supprimant certains écarts fonctionnels. Ce mécanisme
influe sur la durée des tâches de conception et de développement du code
personnalisé qui est requis pour résoudre ces écarts. Il réduit le temps
nécessaire à la mise en œuvre des formations et tests relatifs à ces
personnalisations. Concernant le plan de projet, il implique les activités
suivantes : 2.5.1, 2.6.2, 3.5.0, 3.6.1 et 4.2.1
3. Quels autres événements peuvent nécessiter la mise à jour du plan de projet ?
RÉPONSE TYPE : Diverses raisons peuvent justifier la modification
du plan de projet. Elles incluent notamment la modification du périmètre,
des problèmes de qualité ou un changement apporté à l'un des éléments
de conception

de conception.
RÉPONSE TYPE : 39 jours, du 27/05/10 au 17/07/10

de développement.


de déploiement.
7. Quelle est la durée entre le début du projet et la fin (planifiée) de la phase

de déploiement ?
RÉPONSE TYPE : De l'analyse au déploiement : 158 jours, du 30/03/10
au 13/11/10
8. Quelles phases et activités spécifiques sont liées à la remise des documents

de conception fonctionnelle (FDD, Functional Design Document) ?
Pour quelles dates ces activités sont-elles planifiées ?
RÉPONSE TYPE : Phase de conception : activités 2.4.2 pour les adéquations
le 04/06/10 et activités 2.5.1 pour les écarts du 08/06/10 au 07/07/10
9. Quelles activités incluent des tests et pour quelles dates sont-elles planifiées ?
RÉPONSE TYPE : Phase de conception : activité 2.6 du 03/06/10 au
10/07/10, phase de développement : activité 3.6 du 23/07/10 au 25/09/10,
phase de déploiement : activité 4.6 du 21/10/10 au 30/10/10

10. Quelles tâches liées à la migration des données sont incluses dans les
différentes phases ? Quand sont-elles exécutées ?
RÉPONSE TYPE : Phase d'analyse : migration des données 1.9.0
(incluant la collecte des besoins) du 20/04/10 au 08/05/10 Phase de
conception : migration des données 2.9.0 (incluant le lancement de la
migration des données) du 17/06/10 au 25/06/10 Phase de développement :
migration des données 3.9.0 (incluant le développement et le gel des scripts
de migration des données) du 24/08/10 au 08/09/10 Phase de déploiement :
migration des données 4.9.0 (incluant la migration finale des données vers
l'environnement de production) du 21/10/10 au 03/11/10
11. Quelle est la date de mise en service fixée pour Tailspin Toys et au cours
de quelle phase cette opération est-elle réalisée ?
RÉPONSE TYPE : Phase de déploiement : activité 4.4.1 : le 09/11/10
Atelier 4.2.1 - Représenter les adéquations dans

le document de conception fonctionnelle
1. Combien de besoins sont pris en charge dans ce document de conception
fonctionnelle ?
RÉPONSE TYPE : Un seul besoin est traité dans ce document
2. Quel besoin est traité dans ce document de conception fonctionnelle ?
RÉPONSE TYPE : FR-82, FI-6 : des calculs de comptabilité analytique
doivent pouvoir être effectués. La société souhaite analyser le revenu et
les coûts des différents services, centres de coûts, clients, groupes de clients,
vendeurs et groupes de ventes

3. Quelle solution est choisie pour ce besoin spécifique ?
RÉPONSE TYPE : Ce besoin est implémenté par la configuration
de différentes dimensions financières
Atelier 4.2.2 - Représenter les écarts dans le document

1. Décrivez le contenu de ce document. Quel besoin ce document traite-t-il ?
RÉPONSE TYPE : Ce document décrit la solution proposée pour les écarts
liés à la livraison directe. Il explique comment une solution de code
personnalisé peut être créée et indique les points à prendre en compte
2. La conception proposée répond-elle aux besoins fonctionnels ?
RÉPONSE TYPE : Analysez votre réponse avec les autres participants
3. Le document inclut une présentation de la solution. La présentation proposée

convient-elle au client ? Pourquoi cette condition est-elle nécessaire ?
RÉPONSE TYPE : Une solution appropriée doit être présentée au client
afin qu'il l'accepte et l'approuve
Atelier 4.2.3 - Créer un document de conception

de la solution
1. Indiquez pourquoi un document de conception de la solution doit être utilisé
dans le projet.
RÉPONSE TYPE : Lorsque la documentation relative à la solution,
qui inclut les différents documents de conception fonctionnelle détaillant
les besoins spécifiques, est finalisée, il est recommandé de créer un
document de présentation générale. Ce dernier pourra être utilisé pour
la communication avec les acteurs impliqués

2. uelles informations doivent figurer dans le document de conception

de la solution (SDD) ?
RÉPONSE TYPE : La réponse à cette question est propre à chacun.
Toutes les réponses sont correctes, mais peuvent donner lieu à des
discussions et des activités d'apprentissage entre pairs
3. Examinez le modèle de document SDD. Répertoriez les différentes sections

de ce dernier.
RÉPONSE TYPE : Résumé opérationnel, Situation métier, Vision et
périmètre, Stratégie et concept de la solution et Architecture de la solution
4. La section 4 (Stratégie et concept de la solution) du document SDD contient

différentes sous-sections. Quel type d'informations figure dans cette section ?
RÉPONSE TYPE : Cette section doit indiquer comment la solution
Microsoft Dynamics répondra aux besoins métiers prioritaires du client
5. Le chef de projet peut choisir les documents de conception à utiliser et

définir le contenu devant figurer dans ces derniers. Décrivez le contenu
de la section Architecture de la solution du document SDD.
CONSEIL : examinez le modèle Document de conception de la solution

et l'exemple de document de conception de la solution disponibles dans
Microsoft Dynamics Sure Step pour comprendre dans quelle mesure
les besoins liés au projet déterminent le contenu du document SDD.
RÉPONSE TYPE : La section Architecture de la solution du document SDD
décrit les composants de la solution et les points d'intégration planifiés.
Il peut s'agir de composants standard à configurer et de composants
personnalisés

6. Préparez-vous à participer à la discussion collective à venir. Identifiez

les documents de conception qui vous semblent les plus importants
et les types de projets susceptibles de les utiliser.
Atelier 4.3.1 - Examiner le rapport d'état du consultant

1. Quels consultants interviennent lors du codage personnalisé ?
RÉPONSE TYPE : Jim Wilson et Diane Prescott
2. Combien de jours sont estimés nécessaires pour l'achèvement

de la fonctionnalité Commerce ?
RÉPONSE TYPE : 25 jours
3. Quel consultant a réalisé un rapport d'état de ses propres tâches et quelle est
la période prise en compte dans ce document ?
RÉPONSE TYPE : Jim Wilson a créé un rapport d'état sur son travail pour
la période allant du 20/07/2010 au 27/07/2010
4. Quel travail a été accompli par le consultant au cours de cette période ?
RÉPONSE TYPE : Jim Wilson a achevé la fonctionnalité requise
pour TR-12. Il estime qu'il a besoin de 15 heures supplémentaires pour
traiter TR-16 et 19 ; la date d'achèvement prévue est fixée au 04/08/10

5. Quelles réalisations Jim Wilson planifie-t-il pour la période suivante ?
RÉPONSE TYPE : Achèvement de la fonctionnalité de livraison
directe TR-12/16/19, test unitaire de la livraison directe TR-12/16/19 et
lancement des tâches liées à la fonctionnalité d'approbation des commandes
fournisseur AS-7
6. Que pensez-vous du rapport d'état de Jim Wilson du point de vue

de la gestion de projet ?
RÉPONSE TYPE : Jim Wilson a pris du retard par rapport à l'agenda,
ce qui aboutit à un dépassement des délais et du budget. Il n'est pas sûr
qu'il parvienne à fournir les prochains livrables planifiés. Son rapport est
incomplet et ne donne aucune explication concernant son retard. Il n'a pas
signalé de problèmes et n'a pas commencé les tests. Il prétend avoir satisfait
un besoin, mais étant donné qu'aucun test n'a été effectué, des actions
correctives sont à prévoir
Atelier 4.3.2 - Créer le rapport d'état du projet

1. Quelles informations essentielles avez-vous choisi de communiquer dans
le rapport d'état du projet ?

Atelier 4.4.1 - Test unitaire et fonctionnel

1. Indiquez les domaines fonctionnels pour lesquels aucun script de test
n'a été créé. Pour quelle raison ?
RÉPONSE TYPE : Aucun script de test n'a été créé pour les domaines
fonctionnels suivants : Comptabilité, Comptabilité client, Ressources,
Planification générale, Production, Atelier, Projet, Ressources humaines
et Paie. Étant donné qu'il n'existe aucun besoin de personnalisation pour
ces domaines, aucun code personnalisé n'est développé ni testé
2. Pour quels domaines fonctionnels ces scripts de test sont-ils créés ?
RÉPONSE TYPE : Ces scripts de test sont créés pour les domaines
fonctionnels suivants : Comptabilité fournisseur, Stock, Achats, Ventes,
Gestion des entrepôts et Contrôle qualité
3. Les scripts de test créés sont-ils suffisants ? Quel document permet

de vérifier ce point ?
RÉPONSE TYPE : Oui, pour chaque besoin de personnalisation, un script
de test au moins a été créé. Comparez ces scripts à la matrice détaillée
des écarts, aux différents documents de conception fonctionnelle ou aux
documents de conception technique qui sont créés pour chaque écart
ou personnalisation.

4. Qui est chargé d'exécuter les tests unitaires et fonctionnels ?
RÉPONSE TYPE : Pour Trey Research : les consultants développement
(Jim Wilson, Josh Pollock et Diane Prescott) et le consultant applicatif
(Brian Burke). Pour Tailspin Toys : les utilisateurs clés (Peter Houston,
Russell King, Shawn Richardson et Mike Nash)
5. Dans quel document les résultats des tests sont-ils examinés ? Localisez
ce document et ouvrez-le afin de l'examiner.
RÉPONSE TYPE : La matrice du scénario de test unitaire et fonctionnel
peut être mise à jour avec les résultats des tests. Différentes colonnes
(une pour les consultants et une autre pour les clients) permettent d'indiquer
si le test a réussi ou échoué

RÉPONSE TYPE : Pour le contrôle qualité, aucun test n'a été effectué pour
le moment car le codage personnalisé n'est pas terminé (voir les rapports
d'état des consultants). Des problèmes ont également été identifiés pour les
domaines Stock et Gestion des entrepôts. Toutefois, ils n'ont pas interrompu
le projet. Ils seront résolus ultérieurement et ne devraient pas compromettre
la réalisation du projet

7. Examinez le document Modèle de script de test fonctionnel et unitaire

disponible dans Microsoft Dynamics Sure Step. En quoi diffère-t-il du
Modèle de script de test fonctionnel/unitaire examiné précédemment ?
Utiliserez-vous systématiquement les deux documents ?
RÉPONSE TYPE : Le document détaillant le script de test unitaire et
fonctionnel peut servir à enregistrer les détails d'un script de test particulier
et les résultats, alors que la matrice du script de test unitaire et fonctionnel
récapitule les résultats de tous les scripts de test. Vous pouvez utiliser
ou non les deux documents selon le type de projet et les besoins associés.
Soyez prêt à donner votre avis sur l'utilité de chaque document
Atelier 4.4.2 - Test d'acceptation par les utilisateurs

1. Selon quel principe le modèle est-il divisé ?
RÉPONSE TYPE : Chaque matrice contient des scripts de test pour
un domaine fonctionnel spécifique
2. Qui est chargé d'exécuter les tests d'acceptation par les utilisateurs ?
RÉPONSE TYPE : Les utilisateurs clés de Tailspin Toys (Peter Houston,
Russell King, Shawn Richardson et Mike Nash)
3. Dans quel environnement est-il préférable d'exécuter le test d'acceptation

par les utilisateurs ? Quand cet environnement a-t-il été configuré ?
RÉPONSE TYPE : L'environnement de transit est recommandé.
Cet environnement a été configuré lors de la phase de conception
et mis à jour lors du développement du code personnalisé


RÉPONSE TYPE : Initialement, un petit nombre de tests a échoué dans les
domaines fonctionnels suivants : Comptabilité, Comptabilité client, Stock,
Achats et Planification générale. Certains problèmes ont été résolus avant
que le deuxième testeur ne procède aux tests. D'autres tests ayant échoué
suite à des problèmes mineurs de présentation feront l'objet d'actions
correctives ultérieurement et ne compromettent pas la réalisation du projet
5. Tous les tests ayant été effectués, quelles sont les étapes suivantes logiques
du projet de Tailspin Toys ?
RÉPONSE TYPE : En tant que chef de projet, obtenez l'acceptation totale
du client pour démarrer les activités de mise en service et clôturer le projet.
Cette étape permet de préparer la phase d'exploitation, qui est la dernière
phase du projet
6. Compte tenu des résultats des tests d'acceptation par les utilisateurs, pensez-
vous que la société Tailspin Toys est prête à signer l'acceptation du système
complet ?
RÉPONSE TYPE : Étant donné que seul un petit nombre de tests a échoué
et qu'ils ont une incidence limitée, Tailspin Toys devrait pouvoir poursuivre
le projet, avec l'assistance appropriée
7. Pensez-vous que, si tous les tests avaient réussi, l'étape finale du projet
aurait-pu être automatiquement atteinte ?
RÉPONSE TYPE : La réussite des tests doit permettre d'atteindre les étapes
finales d'un projet, mais cette possibilité n'est en aucun cas garantie. Même
à ce stade, des obstacles peuvent se présenter et avoir par exemple pour
conséquence des demandes de modification ou des retards

Atelier 4.6.1 - Créer un plan de transition vers la mise

en service
1. Dans votre plan de projet, examinez l'activité planifiée pour la mise en
service. Combien de jours sont planifiés pour la mise en service ? Est-ce
réaliste compte tenu de l'approche définie dans le plan de transition vers
la mise en service ? Pourquoi ?
RÉPONSE TYPE : La mise en service est prévue pour le 9 novembre 2010,
sur une durée d'un jour. Sachant que, comme convenu, la mise en service
sera effectuée service par service, ce plan n'est pas très réaliste
2. Quel est l'impact de votre décision précédente ?
RÉPONSE TYPE : Comparativement aux prévisions initiales, la mise en
service prendra plus de temps ; par conséquent, le plan de projet devra être
adapté, et la phase d'exploitation et la fermeture du projet seront reportées
à une date ultérieure
3. Est-ce que certains sites requièrent un accès distant à la solution Microsoft

Dynamics ERP ? Si oui, quels services nécessitent ce type d'accès et qui
est chargé de le configurer ?
RÉPONSE TYPE : Les entrepôts de Boston et de Hong Kong
4. Au cours de quelles activités précédentes les rôles de sécurité sont-ils définis

? Brian Burke aura besoin de cette information pour créer les différents
utilisateurs dans l'environnement de production.
RÉPONSE TYPE : Phase de développement - 3.4.1 et 3.4.2



Langue

FRFR Erp 04

Transféré par

Informations du document

Titre original

Copyright

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 :

FRFR Erp 04

Titre original :

Transféré par

Droits d'auteur :

Chapitre 4 : Réalisation et contrôle du projet au cours des phases…

CHAPITRE 4 : REALISATION ET CONTROLE

• Découvrir comment planifier dès le départ la phase de déploiement

La liste suivante répertorie les activités de gestion de projet des différentes

• Planification et exécution des tâches d'assurance qualité

Supports de formation pour Microsoft Dynamics® 4-1

• Gestion permanente du temps et des coûts

Elle inclut la configuration de la solution Microsoft Dynamics ERP globale,

FIGURE 4.1 CHRONOLOGIE DE LA PHASE DE CONCEPTION

4-2 Supports de formation pour Microsoft Dynamics®

FIGURE 4.2 CHRONOLOGIE DE LA PHASE DE DEVELOPPEMENT

Supports de formation pour Microsoft Dynamics® 4-3

FIGURE 4.3 CHRONOLOGIE DE LA PHASE DE DEPLOIEMENT

4-4 Supports de formation pour Microsoft Dynamics®

L'objectif de la planification de projet au cours de ces phases consiste à analyser

La planification du projet implique la mise à jour du plan de projet de façon

La planification du projet dans le cadre de la phase de conception peut également

La planification du projet comprend également la mise à jour hebdomadaire des

Il est élaboré lors de la phase de conception de façon à laisser suffisamment

Supports de formation pour Microsoft Dynamics® 4-5

Atelier 4.1.1 - Créer le plan de déploiement

La phase d'analyse est terminée et le lancement de la phase de conception est

Notez que le plan de déploiement est un document évolutif que vous

4-6 Supports de formation pour Microsoft Dynamics®

Étape par étape

1. Quelles sont les activités de déploiement requises ? Répertoriez-les ici.

Étape 2 - Lire les informations importantes qui sont présentées ci-dessous.

La transition vers la mise en service doit s'effectuer le plus facilement possible.

Comme convenu, le service informatique interne de Tailspin Toys gérera

Mike Nash sera entièrement responsable de la préparation des différents

Supports de formation pour Microsoft Dynamics® 4-7

Tailspin Toys a décidé de procéder à l'arrêt du système hérité immédiatement

Si la diversité des sites ne soulève aucune difficulté, la taille des différents

• Migration des données • Sécurité -

4-8 Supports de formation pour Microsoft Dynamics®

• Contrôle qualité • Commerce -

• Service clientèle • Commerce -

Étape 3 - Localiser et ouvrir le plan de déploiement.

Examinez le contenu et la présentation du plan de déploiement disponible

CONSEIL : vous trouverez l'activité et le modèle correspondant au plan

Supports de formation pour Microsoft Dynamics® 4-9

Étape 4 - Créer le plan de déploiement de Tailspin Toys.

Essayez de formaliser les informations fournies à l'étape 2 dans les sections

2. À quelles autres questions devez-vous répondre pour achever le plan

4-10 Supports de formation pour Microsoft Dynamics®

Atelier 4.1.2 - Mettre à jour le plan de projet

Vous allez utiliser le même scénario que dans l'atelier 4.1.1.

Nous sommes le 27 mai 2010 et vous procédez à la planification du projet. Cette

Étape par étape

Supports de formation pour Microsoft Dynamics® 4-11

2. Examinez le plan de projet correspondant à un type de projet standard.

3. Quels autres événements peuvent nécessiter la mise à jour du plan de projet ?

Étape 2 - Examiner le plan de projet mis à jour.

Au cours du cycle de vie du projet (phases de conception, de développement

4. À partir du plan de projet mis à jour, déterminez la durée de la phase

4-12 Supports de formation pour Microsoft Dynamics®

5. À partir du plan de projet mis à jour, déterminez la durée de la phase

6. À partir du plan de projet mis à jour, déterminez la durée de la phase

7. Quelle est la durée entre le début du projet et la fin (planifiée) de la phase

Supports de formation pour Microsoft Dynamics® 4-13

8. Quelles phases et activités spécifiques sont liées à la remise des documents

4-14 Supports de formation pour Microsoft Dynamics®

Supports de formation pour Microsoft Dynamics® 4-15

Les livrables de conception de la solution peuvent inclure les éléments suivants :