Objectifs de la Certification Dynamique

Le schéma suivant rappelle le positionnement de la Certification Dynamique dans l’enchaînement des opérations de mise en œuvre d’un nouveau Système d’Information :

La Certification Dynamique s’exécute une fois que les traitements de la plate-forme applicative ont été qualifiés/homologués et que les données reprises ont été certifiées correctes.

La Certification Dynamique consiste à dérouler des scénarios de tests pour simuler le fonctionnement de la plate-forme cible avec des données migrées.

Cette étape est essentielle dans le processus de migration car elle a un objectif complémentaire à celui de la Certification Statique.

La Certification Statique vérifie que les données source migrées par les programmes de migration sont conformes aux règles spécifiées (contrôles de masse et contrôles d’échantillons), sans qu’il n’y ait eu aucune transformation des données cible.

La Certification Dynamique va vérifier que les données migrées lors de la Bascule, pourront être utilisées par le nouveau système sans dysfonctionnements.

De nombreux exemples de projets de migration ont démontré l’importance de cette phase...

Organisation de la Certification Dynamique

La Certification Dynamique doit être effectuée sur des données réelles à volume réel.

On verra dans le chapitre Bascule que l’on planifie des Bascules à Blanc (BB) : ce sont des répétitions de la Bascule réelle.

Lors de ces Bascules, l’ensemble des données du Système d’Information source est migré dans le Système d’Information cible.

Plusieurs Bascules à Blanc sont planifiées, espacées de plusieurs semaines (un mois en général), pour permettre de faire le bilan de la Bascule à blanc passée et de mettre en place des actions correctives.

L’intervalle entre deux Bascules à Blanc va être utilisé pour effectuer la Certification Dynamique.

C’est la situation idéale où l’on peut mettre à disposition des équipes un environnement proche de l’environnement de production.

On verra dans le chapitre Environnements techniques l’intérêt d’un tel environnement que l’on appelle de préproduction.

Dans la réalité, la situation n’est pas si idéale car :

La première Bascule à Blanc est en général une Bascule technique qui permet de répéter surtout le process technique, avec toutes les imperfections...

Champ de la Certification Dynamique

1. Les environnements techniques

Avant de démarrer la Certification, il est nécessaire de préciser l’environnement technique sur lequel elle va s’effectuer.

On va décrire les moyens techniques et la logistique nécessaires à la réception :

environnement matériel ;
logiciels de base ;
outils de tests ;
fichiers de tests.

L’approche proposée ici fait état d’un certain nombre d’environnements.

Elle est fonction de l’expérience de migrations de Systèmes d’Information de taille importante.

Cette approche devra être adaptée à chaque contexte, une migration de taille modeste ne nécessitant pas nécessairement des mêmes environnements.

Les éléments présentés dans ce chapitre sont repris dans le chapitre Environnements techniques.

Pour ce qui concerne la Certification Dynamique, il est essentiel de pouvoir disposer d’environnements dédiés.

La stabilité et la maîtrise des opérations passées sur ces environnements sont bien entendu nécessaires au bon déroulement des plans de tests.

Les besoins que l’on identifie généralement sont les suivants :

Deux environnements, utilisables par Flip/Flop et permettant en parallèle :

la qualification par les équipes de certification ;
la préparation et le chargement par les équipes techniques de la version suivante.

Un (ou plusieurs) environnement(s) spécifique(s), pour des applications périphériques à la plate-forme centrale.

Par exemple, dans les Systèmes d’Information bancaires, il est souvent nécessaire de disposer d’environnements spécifiques pour gérer les applicatifs de gestion des crédits.

Ces environnements doivent être opérationnels, c’est-à-dire qu’ils doivent :

être chargés de données réelles, à volume réel ;

Ce chargement est effectué lors des Bascules à Blanc.

contenir les données du paramétrage à jour et validées par les utilisateurs (MOA) ;

De nombreux scénarios tombent généralement en échec, du fait de tables de paramétrage non à jour.

Ce point est d’autant...

Stratégie de Certification

Les scénarios sont ensuite regroupés en lots d’ordonnancement, en fonction de critères :

contexte de déroulement ;
données migrées ;
timing de passage (J, J+1...) ;
version applicative ou fonctionnelle ;
intervenants, etc.

1. Étape 1 : stratégie de tests par domaine fonctionnel

Plusieurs éléments sont à prendre en considération pour définir la stratégie de certification :

Mesurer la sensibilité des différents composants à tester :

Fondamentaux
Nouveaux
Spécificités : volumétrie, particularités, migration des données, paramétrage
Écarts identifiés lors de l’étude initiale

Identifier les principaux flux (informations, financiers) :

Flux inter applications
Flux internes avec applications sur systèmes dédiés
Flux externes

Identifier les principales entrées :

Internes : saisies, flux en provenance d’autres applications
Externes : réception de fichiers clients, organismes externes...

Identifier les principales sorties :

Éditique : éditions transactionnels, courriers clients, états de contrôle
Fichiers : clients, organismes externes

Définir le schéma général des tests à réaliser pour chaque domaine fonctionnel :

Principales procédures à tester
Profondeur des tests
Contexte de données à prendre en compte
Priorisation des composants à tester
Limites avec les autres domaines...

Gestion des anomalies

De même qu’évoquée dans le chapitre Certification Statique, l’exécution des scénarios de Certification Dynamique va faire apparaître des anomalies.

Ces anomalies sont d’autant plus difficiles à diagnostiquer que leur origine peut être multiple :

Anomalie technique

Lorsque la nouvelle plate-forme est mise en œuvre, il y a toujours des détails techniques à mettre au point pour que les environnements soient opérationnels.

Anomalie sur le fonctionnement d’une application

Une application est un enchaînement de composants TP et Batch, qui doivent être tous installés dans le nouvel environnement.

L’absence de l’un de ces composants génère un « abort ».

Les applications testées dans le cadre d’une campagne de Certification Dynamique, ont généralement toutes fait l’objet d’une qualification.

Néanmoins, il se peut qu’il subsiste des anomalies non détectées en qualification.

Anomalie de migration de données

C’est l’objectif principal de la Certification Dynamique qui nous intéresse particulièrement ici.

La Certification Dynamique va permettre de faire fonctionner la plate-forme applicative sur des données migrées et va nécessairement amener des anomalies liées à la reprise des données.

Des exemples ont précédemment été cités où il s’est avéré que la migration de données était incomplète, soit pour des données non (ou mal) renseignées, soit pour des critères de filtrage mal ajustés au fonctionnement de la plate-forme.

Ces anomalies doivent faire l’objet d’une gestion rigoureuse et centralisée, c’est-à-dire qu’elles seront formalisées dans des fiches d’anomalie, détaillées et exhaustives.

De la qualité des informations fournies dans la fiche d’anomalie dépend la rapidité de sa résolution.

Les informations principales sont les suivantes :

Nom/Prénom de la personne à l’origine de la détection de l’anomalie.
Identifiant informatique de l’utilisateur.
Date et heure du test.
Environnement...

Les différents acteurs

La phase de Certification Dynamique va nécessiter plusieurs types d’acteurs :

Chef de projet
Responsables de domaine MOE
Responsables de domaine MOA
Recetteurs
Support MOE
Support Batch

dont les rôles et responsabilités sont définis ci-dessous :

Chef de projet

Définition de la démarche de Certification Dynamique
Définition des plannings et besoins en ressources
Animation et coordination des travaux
Suivi de l’avancement des travaux et du respect des plannings établis
Pilotage des acteurs
Coordination avec les autres projets
Reporting hebdomadaire pour la MOA et la Direction

Responsable de domaine MOE

Dans la phase de construction des plans de certification :

Identification et définition du périmètre des domaines
Suivi de l’avancement, pour livraison aux dates planifiées
Revue des plans de tests rédigés pour chacun des domaines

Dans la phase de déroulement :

Validation de la cohérence des campagnes de tests
Suivi de l’avancement des travaux des campagnes de certification
Validation des procès-verbaux de certification

Coordination entre les différents projets de MOA.

Responsable de domaine MOA

Expertise métiers
Fabrication des livrables pour les différentes phases de recette
Préparation et construction des scénarios de Certification
Planification et l’ordonnancement...

Prononciation de la Certification

La Certification Dynamique a nécessairement une fin, fonction du planning du projet et des échéances qui y sont positionnées.

Il faut donc définir le process qui va permettre de prononcer la Certification.

Il s’agit de préciser les éléments qui vont permettre de valider la conformité des applications recettées avec les cahiers des charges établis.

Trois cas sont à envisager lors de la certification :

Les tests effectués se sont déroulés conformément aux attentes et les résultats obtenus sont conformes aux spécifications.

L’utilisateur qui prononce la certification a pu vérifier que le logiciel mis à sa disposition fonctionnait tel qu’il avait été spécifié.

Si des anomalies ont été détectées lors de la Certification, l’anomalie a été corrigée et l’utilisateur a vérifié que la correction était satisfaisante.

Dans ce cas, l’utilisateur prononce la Certification.

Les tests ont permis de détecter des anomalies qui ont été corrigées, mais il reste encore des anomalies mineures.

Toutes les anomalies bloquantes ou majeures ont été corrigées puis validées. La majorité des anomalies mineures l’ont été...