Secrétariat du Conseil du Trésor du Canada
Symbole du gouvernement du Canada

ARCHIVÉ - Systèmes en cours d'élaboration (Guide de verification) - le 1 mars 1991

Avertissement Cette page a été archivée.

Information archivée dans le Web

Information archivée dans le Web à  des fins de consultation, de recherche ou de tenue de documents. Cette dernière n’a aucunement été modifiée ni mise à  jour depuis sa date de mise en archive. Les pages archivées dans le Web ne sont pas assujetties aux normes qui s’appliquent aux sites Web du gouvernement du Canada. Conformément à  la Politique de communication du gouvernement du Canada, vous pouvez demander de recevoir cette information dans tout autre format de rechange à  la page « Contactez-nous Â».


Exécution de la vérification : la vérification appliquée au processus d'élaboration des systemes

Introduction

Ce chapitre traite du processus de vérification devant être appliqué à chaque étape d'un projet d'élaboration. L'expression « étape » a été retenue pour chacune des composantes chronologiques du CES dans le présent guide pour éviter la confusion avec l'expression « phase » utilisée en vérification.

Portée et objet

La vérification des systèmes en cours d'élaboration a trois objectifs principaux : donner un avis sur l'efficience, l'efficacité et l'économie de la gestion du projet; donner un avis sur le degré auquel le système en cours d'élaboration fournit des pistes de vérification et des contrôles suffisants pour assurer l'intégrité des données traitées et stockées; et donner un avis sur les contrôles exercés pour la gestion du fonctionnement du système. Ces objectifs sont clairement identifiés dans le chapitre 3, à l'intention des vérificateurs, par un A (Contrôle des activités liées au projet), un B (Contrôle de la validité des données), ou un C (Contrôle des opérations du système) comme deuxième indicateur dans les parties relatives aux objectifs, aux critères et aux critères détaillés.

Pour atteindre le premier objectif, le vérificateur assiste aux réunions du comité de projet et du comité directeur, examine la documentation des contrôles du projet et effectue des entrevues. L'accent est mis sur l'établissement, avec le concours de l'entité vérifiée, de normes de contrôle du projet (p. ex., un processus formel d'élaboration des systèmes) et la détermination du degré d'observation de ces normes. Pour exécuter cette activité, le vérificateur doit garder présentes à l'esprit les exigences de l'ancien chapitre 440 du Manuel de la politique administrative du Conseil du Trésor, le contenu de toutes les circulaires, politiques et normes données à l'appendice J, ainsi que la documentation couverte par le Guide de vérification du processus de gestion du BCG.

Pour le deuxième objectif, le vérificateur se limite à examiner la documentation sur le système, comme les spécifications fonctionnelles, pour se former une opinion sur les contrôles. Cette opinion sera fondée sur la mesure dans laquelle le système de technologie de l'information répond aux objectifs généraux en matière de contrôle. Une liste de ces objectifs devrait être fournie à l'entité vérifiée. Il en va de même pour le troisième objectif, les contrôles opérationnels du système. Le vérificateur devrait fournir à l'entité vérifiée une liste des contrôles standard, en ce qui a trait aux questions opérationnelles, comme le délai de réponse, l'utilisation de l'unité centrale, et la disponibilité de l'espace d'accès direct, qu'il a utilisées comme critère d'évaluation.

Phases de la vérification

La vérification d'un système en cours d'élaboration demande l'exécution de certaines procédures à chaque étape du CES. Bien que cette méthode semble segmenter le processus en vérifications séparées et distinctes, ce n'est pas le cas; la vérification d'une étape ou d'un groupe d'étapes doit tenir compte de toutes les vérifications antérieures (ou de l'absence de vérification) effectuées dans le processus continu d'élaboration d'un système.

Pour effectuer la vérification des systèmes en cours d'élaboration, les activités suivantes, communes à toutes les vérifications faites selon les normes du Conseil du Trésor, doivent figurer à chacune des phases de la vérification :

  1. planification de la mission
  2. examen
  3. évaluation
  4. corroboration
  5. rapport et suivi.

Les activités qui précèdent se tiendront pour la plupart à l'occasion d'une vérification de système en cours d'élaboration, avec une certaine variation dans leur application.

Aspects particuliers de la phase de planification

Toutes les phases de la vérification d'un CES doivent être planifiées et incluses dans la planification initiale de la vérification d'un système en cours d'élaboration. A mesure que la vérification du CES avance, le plan de vérification doit préciser quelle étape fait l'objet de la vérification et mettre à jour les plans visant les autres étapes.

Phase d'examen et d'évaluation

L'activité d'examen et d'évaluation sera poursuivie à chacune des phases de vérification pour vérifier si le système suit le processus du CES. Cependant, puisqu'on commence à documenter et à programmer les contrôles au cours de l'étape de faisabilité, l'examen et l'évaluation de l'intégrité des données et des contrôles du système ne peuvent être effectués qu'aux phases de l'étude de faisabilité, d'analyse générale, d'analyse détaillée, de mise en oeuvre, de mise en place et de vérification des activités postérieures à la mise en place.

Phase de corroboration

Tout au long du processus d'élaboration, le vérificateur vérifiera la conformité de celui-ci avec le CES (voir l'approche détaillée en 4.A.10.1). Le vérificateur ne testera pas les contrôles mais examinera plutôt leur conformité avec les normes de test pour le CES. Là où les tests n'ont pas été suffisants, le vérificateur doit immédiatement en aviser les gestionnaires du projet. Les tests sont une fonction se rapportant à l'utilisateur et à l'équipe de projet. La participation directe du vérificateur à l'exécution des tests peut compromettre son objectivité, mais il peut décider d'effectuer certains tests à nouveau, afin d'appuyer les conclusions du contrôle.

Aspects particuliers de synchronisation des rapports

Une caractéristique importante des vérifications des systèmes en cours d'élaboration est que l'on y évite un rattrapage coûteux des contrôles, ce qui ne peut toutefois être réalisé que là où la communication entre le vérificateur et le service vérifié permet de prendre rapidement des mesures pour corriger les points relevés par la vérification. Pour bien servir les intérêts de la haute direction, les rapports de vérification doivent suivre le processus d'élaboration du système. Toutefois, dès qu'il peut les étayer, le vérificateur doit également communiquer ses constatations à une personne au niveau de gestionnaire de projet. Pour garantir l'objectivité de la vérification et tenir la haute direction au courant des activités de la vérification des systèmes en cours d'élaboration, la présentation de rapports sommaires de vérification devrait coïncider avec les étapes du projet et les points de contrôle. Par exemple, le processus peut prévoir les étapes ci- dessous :

  • lancement d'un projet
  • étude de faisabilité
  • conception générale
  • conception détaillée
  • mise en oeuvre
  • mise en place
  • activités postérieures à la mise en place.

Dans ce cas, les sorties de vérification comporteraient un protocole de plan de vérification devant être présenté à tous les niveaux de gestion pendant la vérification de l'étape de lancement du projet ainsi que des rapports sommaires de vérification, selon le processus ordinaire de présentation de rapports de vérification, après chacune des étapes de vérification suivantes.

Par ailleurs, les activités de vérification des systèmes en cours d'élaboration doivent être prévues de manière à aider les hauts fonctionnaires lorsque les présentations au Conseil du Trésor doivent être approuvées par le ministère. Habituellement, le vérificateur émet un avis sur le caractère raisonnable des renseignements sur les coûts/avantages que renferme la présentation, mais il peut également entamer une vérification d'autres renseignements contenus dans la présentation.

Note

Les études de CES présentées ci-dessus s'appliqueraient surtout aux nouveaux systèmes majeurs en cours d'élaboration ou à des changements importants apportés aux systèmes existants. Dans l'élaboration des systèmes plus petits, ou lorsque des changements mineurs sont apportés à des systèmes existants, on peut regrouper les étapes de CES ou en abandonner quelques-unes. Dans ce dernier cas, l'équipe de projet doit faire particulièrement attention à ne pas léser le système. Par exemple, si l'on ne prend pas suffisamment les solutions de rechange en considération dans l'étape de faisabilité, il peut en résulter la sélection d'une solution de rechange inappropriée. Le facteur coûts, lorsqu'il est décidé d'abandonner une étape, doit être considéré en regard du risque encouru.

La création de prototypes a été décrite au chapitre 2. Les questions et les contrôles se rapportant à cette technique sont compris dans les étapes de lancement et de faisabilité qui suivent.

Les projets de mise-à-jour, c'est-à-dire les améliorations apportées aux systèmes déjà en place, peuvent être considérés comme assez importants pour être envisagés comme des projets de CES complets en eux-mêmes. Les points de vérification seraient alors identiques à ceux décrits ci-dessous.

On doit définir des normes d'élaboration pour chaque étape du CES et s'y tenir pour assurer une cohérence dans l'élaboration de tous les projets des ministères. Néanmoins, un ministère donné pourrait définir un ensemble séparé de normes fondées sur le genre de projet qui est entrepris (élaboration de système majeur ou mineur), ce qui contribuera à assurer que des normes minimales sont appliquées dans les activités d'élaboration des systèmes mineurs.

Finalement, lorsqu'il établit si un système est assez petit pour justifier le regroupement ou l'élimination de certaines étapes du CES d'une vérification, le vérificateur doit garder à l'esprit que certains changements relativement mineurs peuvent être très importants du point de vue des contrôles. L'importance d'une modification apportée à un système doit être évaluée avec soin si l'on pense à s'écarter des normes.

Objectifs de contrôle pour chacune des étapes

Voici maintenant les objectifs de contrôle, les critères et les critères détaillés se rapportant à chaque étape d'élaboration de projets pour le contrôle des activités liées au projet (A), le contrôle de la validité des données (B) et le contrôle d'opérations du système (C).

Les premiers contrôles sont naturellement examinés à chaque étape d'élaboration afin que l'on puisse se faire une opinion sur l'efficience, l'efficacité et l'économie de l'exécution du projet. Heureusement les contrôles de l'entrée, de l'intégrité des données et de la gestion du système peuvent n'être examinés que lors des étapes d'étude de faisabilité, d'analyse générale, d'analyse détaillée et de mise en oeuvre, afin de permettre des données de vérification opportunes (voir figure 4). L'étape d'étude de faisabilité est incluse, pour le cas où les exigences en matière de contrôle peuvent se rapporter au choix d'une approche d'analyse.

Il est à noter que si certains critères de contrôle des projets sont répétés d'une étape de vérification à une autre, le vérificateur doit traiter chaque phase de vérification du guide comme une phase distincte. Cela signifie qu'il doit tenir compte des objectifs de toutes les phases de vérification antérieures à la phase où il est rendu lorsqu'il détermine quels objectifs appliquer à la phase de vérification.

Finalement, les sections du chapitre sont identifiées par des chiffres et des lettres qui permettent au lecteur de savoir à quelle phase et à quel objectif de vérification il est rendu dans le texte. Le diagramme qui suit permet de bien comprendre le système d'identification :

Figure 4 : Activités de vérification pour chaque étape d'élaboration

Étape Projet Données Systeme
Lancement  OUI NON NON
Étude de faisabilité OUI OUI OUI
Conception générale OUI OUI OUI
Conception détaillé OUI OUI OUI
Mise en oeuvre OUI OUI** OUI*
Mise en place OUI NON NON
Activités postérieures à la mise en place OUI OUI** OUI**

OUI signifie qu'une activité de vérification doit avoir lieu à ce stade.

NON signifie qu'aucune activité de vérification ne doit avoir lieu à ce stade.

* Les contrôles du système font partie de l'examen des essais effectués lors de cette phase. (Voir le critère 5.A.3.2 à l'appendice F).

** Comprend la réexécution de certains tests de contrôle.

Les renseignements de vérification que renferme le reste du chapitre et les appendices connexes sont identifiés au moyen d'un numéro de classification Dewey à quatre zones (voir la figure 5). Grâce à ce numéro, le lecteur pourra savoir où il est rendu dans le texte.

Figure 5 : Exemple du Système de classification Dewey

1.A.1.1

Étapes du ces : 

  • Lancement
  • Faisabilité
  • Conception générale
  • Conception détaillée
  • Mise en oeuvre
  • Mise en place
  • Activitées postérieures à la mis en place

1.A.1.1

Objectifs :

A = Contrôle des activités liées au projet

B = Contrôle de la validité des données

C = Contrôle d'opérations du système

1.A.1.1

Critères

1.A.1.1

Procédures de vérification

1. Étape de lancement du projet

Il est essentiel que la participation du vérificateur soit communiquée officiellement au comité directeur des systèmes du ministère, ce qui s'effectuera par l'entremise d'un protocole formel stipulant la nécessité de la présence du vérificateur aux réunions de l'équipe de projet et du comité directeur.

Après que le vérificateur aura terminé la phase de planification de la vérification de l'étape de lancement, un protocole formel pour le plan de vérification sera publié, indiquant la participation des vérificateurs pour le reste du projet.

On examinera la conformité avec les exigences du CES pendant cette étape et on transmettra au comité directeur tout écart majeur.

Questions concernant le contrôle des activités liées au projet (A)

L'expression « utilisateur ou direction des utilisateurs » utilisée dans les objectifs, les critères ou les critères détaillés signifie la « collectivité des utilisateurs », habituellement représentée par un ou plusieurs membres de l'équipe de projet. La « collectivité des utilisateurs » peut représenter une ou plusieurs entités distinctes au sein du ministère. Le vérificateur doit veiller à la juste représentation de la « collectivité » au sein de l'équipe.

On doit justifier clairement l'entreprise d'un nouveau processus d'élaboration, généralement par une analyse économique; cependant, dans certains cas, on peut le faire en évaluant le besoin de services améliorés ou supplémentaires, ou d'autres préoccupations non quantifiables. Quoi qu'il en soit, il doit exister une forme quelconque de justification du projet.

La documentation des contraintes s'appliquant au projet (dans les documents relatifs à celui-ci) et l'identification préliminaire des conditions qui serviront à mesurer l'efficacité du nouveau système garantissent que la décision de lancer le projet a été prise après considération de l'information nécessaire.

Le contrôle, l'organisation, les responsabilités et les autorités s'appliquant au projet doivent être établis clairement.

Risques principaux

On doit intégrer au plan de vérification des activités de vérification visant à traiter des risques principaux suivants, qui pourraient empêcher que les exigences de l'utilisateur ou du projet soient satisfaites :

  • le caractère vague des problèmes relevés et de la portée du projet;
  • l'acceptation d'un plan de projet qui ne contribue pas aux objectifs du ministère ou de l'organisme ou à sa planification stratégique;
  • la faiblesse de la gestion du projet, tant en ce qui concerne les ressources humaines que financières (établissement d'un budget);
  • l'insuffisance de l'évaluation du risque lié au projet;
  • l'insuffisance de la documentation des questions touchant la sécurité et la protection des renseignements personnels, y compris le niveau d'autorisation de sécurité et de fiabilité, exigé et réel, pour les membres de l'équipe.

Objectif

1.A Déterminer si le projet a été lancé officiellement et si des contrôles adéquats sont exercés.

Critères

1.A.1 Le rapport sur le lancement du projet (ou un document semblable) indique que le projet est nécessaire.

1.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données jugent le projet nécessaire.

1.A.3 Le rapport sur le lancement du projet indique l'organisation du projet.

1.A.4 Le rapport sur le lancement du projet indique les étapes de réalisation du projet ainsi que les tâches et les responsabilités.

1.A.5 Le rapport sur le lancement du projet renferme un plan de travail qui indique, notamment, les délais fixés.

1.A.6 L'organisation du projet, les étapes de réalisation et le plan de travail ont été approuvés officiellement par un gestionnaire de niveau approprié.

Note 1 : Cet objectif et les critères qui s'y rapportent correspondent aux programmes de vérification de l'appendice B qui portent le même nom.

Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun objectif relatif au contrôle de la validité des données (B) ou au contrôle des opérations du système (C) pour l'étape de lancement (1) puisqu'il n'est pas nécessaire de documenter les contrôles à cette étape (voir la figure 3).

2. Étape de l'étude de faisabilité

Lors de l'étape de lancement du projet, le problème a été décrit. L'objectif de cette étape est donc d'étudier les exigences des utilisateurs en général afin de déterminer la solution conceptuelle qui convient, en termes de compatibilité organisationnelle, de justification économique et d'adaptation technique. On préparera des spécifications détaillées lors de l'étape suivante en s'appuyant sur ces exigences, généralement regroupées dans le DOCUMENT DES EXIGENCES DE L'UTILISATEUR.

Questions concernant le contrôle des activités liées au projet (A)

Le vérificateur doit s'assurer que les exigences de l'utilisateur ont été relevées et documentées en détail. L'équipe du projet doit réunir avec grand soin l'information contenue dans le document sur les exigences des utilisateurs grâce à ceux d'entre eux qui, ne connaissant pas le potentiel d'un nouveau système, ne limitent pas pour autant leur définition des exigences.

Toutes les solutions de rechange pratiques doivent avoir été relevées et analysées. Les faits et les évaluations coûts/avantages utilisés dans l'analyse doivent être raisonnables et provenir de sources fiables. Les conclusions doivent être la suite logique de l'analyse.

Les évaluations des ressources et du temps nécessaires doivent être complètes et raisonnables. Du fait que ces évaluations serviront au contrôle budgétaire et au contrôle du projet, il est impératif que toute l'information soit convenablement détaillée.

Risques principaux

On doit intégrer au plan de vérification des activités liées aux risques principaux suivants :

  • l'information fournie à la gestion dans des buts d'évaluation, d'approbation et de planification peut être incomplète ou inexacte, voire les deux;
  • la solution de rechange optimale n'a pas été retenue;
  • la planification, le contrôle et l'administration sont inadéquats;
  • de nombreux utilisateurs éprouvent de la difficulté à vérifier leurs besoins précédemment exposés lorsqu'ils ont à faire face à un document volumineux. Le vérificateur doit déterminer si l'équipe de projet a utilisé une méthode valable pour assurer la participation active de l'utilisateur en vérifiant les exigences de celui-ci (ainsi, la création de prototypes décrite);
  • il est possible que la gestion supérieure traite cette étape d'approbation de façon rapide étant donné qu'elle requiert peu de ressources. Dans ce cas, il pourrait en résulter que les phases subséquentes soient exécutées sans que cette phase importante ait été finalisée.

Objectif

2.A Déterminer si une étude de faisabilité (y compris un plan de projet global) a été réalisée dans le but de trouver la solution idéale à un problème donné du point de vue organisationnel, économique et technique.

Critères

2.A.1 Le rapport sur les besoins des utilisateurs (ou un document de ce genre) examine les besoins des utilisateurs.

2.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que la définition des besoins est précise et complète.

2.A.3 L'étude de faisabilité (ou un document de ce genre) renferme une analyse des solutions de rechange.

2.A.4 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'analyse des solutions de rechange est fondée sur des données précises et complètes, y compris les contraintes et les risques, et approuvent les recommandations formulées.

2.A.5 Le rapport sur l'analyse coûts/avantages (ou un document semblable) renferme une estimation des ressources humaines et financières requises.

2.A.6 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'analyse des coûts/avantages est fondée sur des données précises et complètes, et approuvent la solution de rechange recommandée.

2.A.7 Le gestionnaire responsable du projet s'est inspiré de la solution de rechange recommandée dans l'analyse des coûts-avantages pour préparer un sommaire des aptitudes personnelles :

  • aptitudes requises, administratives et techniques
  • niveau de compétence requis
  • nombre d'employés requis
  • niveau d'autorisation nécessaire

2.A.8 Les comptes rendus des réunions du comité directeur ou des documents de ce genre.

2.A.9 Le rapport sur l'étude de faisabilité (ou un document de ce genre) compare l'état d'avancement du projet au plan de travail contenu dans le rapport sur le lancement du projet.

2.A.10 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'étude de faisabilité (ou un document semblable) est fondée sur des données précises et complètes, et l'approuvent ou jugent que les problèmes ont été réglés à leur satisfaction.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice B qui portent le même nom.

Intégration du contrôle de la validité des données (B) et d'opérations du système (C)

Dans cette étape d'élaboration, l'utilisateur, qui est en fin de compte responsable de l'intégrité des données, doit faire connaître ses exigences se rapportant au contrôle de la validité des données (B). Ces exigences doivent être prises en considération au moment de mener l'étude de faisabilité et l'analyse coûts/avantages afin d'assurer leur inclusion dans le système. Les exigences se rapportant au traitement et au contrôle de la sécurité ou de la protection des renseignements personnels doivent être incluses dans le document des exigences de l'utilisateur, ou le prototype équivalent.

Les contrôles d'opérations du système (C) sont les contrôles nécessaires pour s'assurer que le système continue à fonctionner de façon efficiente et efficace après sa mise en place. Ces contrôles diffèrent des contrôles sur les données et l'information et ont des objectifs différents. Les contrôles de la gestion, portant sur le fonctionnement du système, doivent correspondre à la définition des exigences pour le système lui-même et à l'analyse coûts/avantages.

Risques principaux

On doit intégrer au plan de vérification des activités de vérification liées aux risques principaux suivants :

  • toute évaluation inadéquate par la gestion supérieure des utilisateurs de la documentation sur les exigences en matière de contrôle des données, ainsi que la solution de rechange retenue au moment de l'approbation de cette phase; et
  • le manque de précision de la part de l'utilisateur ou de l'opérateur en matière de contrôle de gestion du système.

Objectif

2.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées, et si des mesures de sécurité, de protection des renseignements personnels et d'accès à l'information sont prévues.

Critères

2.B.1 La fiche de contrôle (ou un document de ce genre) indique les mesures de contrôle prévues.

2.B.2 Le représentant des utilisateurs a pris bonne note du niveau de sécurité, de protection des renseignements personnels et d'accès à l'information des données emmagasinées par le système; et sait dans quelle mesure le système et les données sont sensibles en cas de perte, de destruction, d'accès non autorisé et de modifications.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice C qui portent le même nom.

Objectif

2.C S'assurer que les contrôles en place assurent le fonctionnement efficient, efficace et économique du système.

Critère

2.C.1 La configuration de base (ou un document de ce genre) fait état des exigences en matière de contrôle de la gestion du système.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice C qui portent le même nom.

3. Étape de conception générale

A cette étape, on prépare des spécifications détaillées des exigences de l'utilisateur à partir de la solution de rechange au système conçu qui a été approuvée à l'étape précédente. Les spécifications qui en résultent sont exprimées dans les termes de ceux qui remplissent les fonctions de gestion visées et sont libres de tout point d'analyse technique. Les spécifications fonctionnelles seront traduites en une analyse de système à l'étape suivante.

Les questions de sécurité doivent demeurer une préoccupation de la vérification à cette étape, ainsi qu'on l'a noté à la fin du chapitre 2.

Questions concernant le contrôle des activités liées au projet (A)

On doit avoir surveillé la performance des projets pendant l'étape de conception générale, par rapport aux plans et budgets établis lors de l'étape de faisabilité, et justifier les écarts auprès des autorités de projets.

Le système, dans son analyse, doit répondre aux exigences des utilisateurs. Les points concernant les contrôles (financier et opérationnel) doivent avoir été traités. Dans certains cas, le mandat de la vérification peut demander l'évaluation de ces contrôles d'application.

On doit s'être occupé des éléments manuels et automatisés du nouveau système.

La documentation doit traiter suffisamment en détail de tous les éléments du système pour permettre une analyse détaillée du système.

Risques principaux

Dans le plan de vérification, on doit prendre en considération les risques principaux suivants :

  • le relevé et la définition incomplets ou inexacts des facteurs clés;
  • le manque de correspondance entre les besoins définis et réels;
  • l'évaluation insuffisante des coûts/avantages du système; et
  • la non obtention de l'approbation ou de l'autorisation aux points de contrôle désignés.

Objectif

3.A S'assurer que la conception générale du système est fondée sur les constatations de l'étude de faisabilité, qu'elle produit une description fonctionnelle du manuel d'instructions et des procédés informatiques, et qu'elle donne lieu à la conception d'un système permettant d'obtenir un engagement quant à la poursuite de l'élaboration.

Critères

3.A.1 Le rapport sur la configuration du système (ou un document de ce genre) fait état des caractéristiques du système.

3.A.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que la configuration du système est précise et complète.

3.A.3 Le dictionnaire ou répertoire des données a été mis à jour en fonction de la configuration du système.

3.A.4 Toutes les ressources humaines nécessaires ont été affectées à la réalisation du projet.

3.A.5 Le calendrier des réunions du comité directeur (ou un document de ce genre) indique la date des réunions prévues, ainsi que les questions qui seront à l'ordre du jour.

3.A.6 Le rapport sur l'analyse générale (ou un document de ce genre) renferme une étude du projet par rapport au budget et au calendrier contenus dans l'étude de faisabilité.

3.A.7 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que le rapport sur l'analyse générale est complet et précis, et l'approuvent.

3.A.8 Une analyse de l'incidence sur les ressources humaines est planifiée.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.

Intégration au système du contrôle de la validité des données (B) et d'opérations du système (C)

L'équipe de projet, composée de représentants des utilisateurs et de l'informatique, doit choisir les techniques permettant de satisfaire aux exigences en matière de contrôle élaborées lors de l'étape de faisabilité. Cette sélection n'est limitée que par l'imagination des membres de l'équipe. Le travail du vérificateur à ce point consiste à évaluer le contrôle, et non les capacités techniques des utilisateurs.

Risques principaux

Les activités de vérification intégrées au plan de vérification doivent tenir compte des risques principaux qui suivent :

  • l'inexactitude des données d'un projet doit être prise en compte dans la planification de la vérification afin de déterminer l'étendue, la nature et la synchronisation des procédures de vérification à cette étape et à toutes les étapes de CES subséquentes;
  • le manque de précision, de la part de l'utilisateur, quant aux techniques permettant de satisfaire aux exigences en matière de contrôle de gestion des systèmes, du fait qu'« il est trop tôt pour le savoir ».

Objectif

3.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées.

Critères

3.B.1 Afin de satisfaire aux exigences énoncées dans la liste des contrôles la configuration du système (ou un document semblable) énonce les méthodes de contrôle du traitement des données.

3.B.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que les méthodes de contrôle du traitement des données sont complètes et précises.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.

Objectif

3.C Déterminer si le système fonctionnel est exploité de façon efficace et efficiente.

Critères

3.C.1 Afin de satisfaire aux exigences énoncées dans la liste des contrôles, la fiche de contrôle de gestion (ou un document de ce genre) énonce les méthodes de contrôle de la gestion du système.

3.C.2 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que les méthodes de contrôle de la gestion du système sont complètes et précises.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.

4. Étape de conception detaillee

Pendant l'étape d'analyse détaillée, on traduit les spécifications fonctionnelles préparées aux étapes précédentes en une description du système qui permettra de répondre aux exigences fonctionnelles spécifiées. L'analyse du système sera alors mise en oeuvre dans des systèmes informatisés et manuels lors de l'étape de mise en oeuvre.

Le principal objectif de cette étape est de traduire les spécifications d'analyse des utilisateurs en systèmes, processus de bases de données qui fonctionneront dans le cadre des contraintes de matériel et de logiciels des systèmes.

Points concernant le contrôle des activités liées au projet (A)

On devrait avoir surveillé la performance du projet à l'étape d'analyse détaillée, par rapport aux plans et budgets établis lors de l'étape de faisabilité (ou leur révision subséquente), et justifié les écarts auprès des autorités du projet.

Tous les éléments du système devront avoir été conçus en détail. Les éléments manuels et informatisés, ainsi que les caractéristiques de contrôle du système devront avoir été envisagés.

Si le mandat de vérification comprend l'évaluation des contrôles d'application, un examen, décrit dans le Guide de la vérification des contrôles d'application peut se révéler nécessaire.

L'analyse détaillée est l'analyse complète et finale du système opérationnel, c'est-à-dire qu'il ne doit y avoir aucun défaut ou aucune incohérence technique apparent. Selon le mandat de vérification, le vérificateur peut examiner les preuves que cela a été établi ou s'en assurer directement grâce à une réexécution de l'évaluation.

Risques principaux

Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :

  • Les principes sous-jacents à l'analyse de l'approche des tests peuvent s'avérer inappropriés et mener, par conséquent, à des conclusions fausses.
  • Une information insuffisante sur les caractéristiques du matériel et des logiciels, ainsi que sur les conditions des contrats peuvent empêcher des choix optimaux.
  • L'évaluation des coûts et avantages du système peut être inexacte ou incomplète.
  • L'étape de mise en oeuvre peut avoir été amorcée sans que la planification et les essais nécessaires aient été achevés.

Objectif

4.A Déterminer si une conception détaillée a été mise au point à partir des caractéristiques fonctionnelles établies au moment de la conception générale.

Critères

4.A.1 Le rapport sur la conception détaillée (ou un document de ce genre) fait état des caractéristiques de la programmation.

4.A.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que les caractéristiques sont précises et complètes.

4.A.3 Le dictionnaire ou répertoire des données a été mis à jour en fonction du document sur les caractéristiques de la conception détaillée.

4.A.4 Le plan de mise à l'essai (ou un document de ce genre) indique les mises à l'essai prévues.

4.A.5 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que le plan de mise à l'essai est précis et complet.

4.A.6 Le plan de mise à l'essai tient compte des besoins des utilisateurs.

4.A.7 Toutes les ressources humaines requises ont été affectées à la réalisation du projet.

4.A.8 Le calendrier des réunions du comité directeur (ou un document de ce genre) fait état de toutes les réunions prévues, ainsi que des questions qui seront à l'ordre du jour.

4.A.9 Le rapport sur la conception détaillée (ou un document de ce genre) examine le projet par rapport au budget et au calendrier établis dans le rapport sur la conception générale.

4.A.10 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la conception détaillée renferme des données précises et complètes, et s'ils l'approuvent.

4.A.11 Une analyse de l'incidence sur les ressources humaines a été effectuée.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.

Intégration au système des contrôles de la validité des données (B) et d'opérations du système (C)

A ce stade de la conception détaillée, les techniques de contrôle de l'application relevées lors de l'étape précédente ont été transformées en contrôles des entrées, du traitement et des sorties.

A beaucoup d'égards, la vérification des contrôles de la gestion des données et des systèmes commence à ressembler à la vérification d'un système en activité. La principale différence est que le vérificateur doit vérifier les tests de l'équipe de projet et ne devrait réexécuter les tests de contrôle que de façon sélective.

Les contrôles d'entrées porteront sur la transmission, l'acceptation, la conversion et la validation des données, ainsi que sur la correction des erreurs. Les contrôles du traitement porteront sur la restriction à l'accès et la vérification de l'intégrité des données entre les étapes du traitement et à l'intérieur des bases de données. Ils minimiseront également l'incidence des pannes des systèmes sur les systèmes en direct. Les contrôles des sorties consistent en un rapprochement et un équilibrage généralisés des fichiers des sorties et des rapports, et portent sur les mesures de sécurité connexes.

Jusqu'à un certain point, la nature des contrôles d'application mis au point sera fonction de leur application à un système particulier. Par conséquent, il n'est pas pratique d'essayer de prévoir l'inclusion des spécifications détaillées de l'analyse des systèmes se rapportant à chaque technique de contrôle. Là encore, l'appendice I contient des renvois à des ouvrages traitant de la vérification des systèmes en activité. En plus d'examiner les tests à entreprendre par l'équipe de projet pour vérifier que ces tests couvrent bien les exigences en matière de contrôle, le vérificateur doit commencer à relever les contrôles devant être testés à nouveau (A NOUVEAU et non pour la PREMIERE FOIS), après que l'on dispose des premiers programmes, c'est-à-dire probablement à la fin de l'étape de mise en oeuvre ou au début de l'étape de mise en place.

Risques principaux

On doit intégrer au plan de vérification des activités de vérification qui traitent du risque principal suivant :

  • la non inclusion de toutes les exigences en matière de contrôle dans le plan des tests.

Objectif

4.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées.

Critères

4.B.1 Déterminer si le plan de mise à l'essai (ou un document de ce genre) fait état des méthodes de contrôle du traitement énoncées dans le rapport sur le contrôle du traitement.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.

Objectif

4.C Déterminer si le système est exploité de façon efficace et efficiente.

Critère

4.C.1 Déterminer si le plan de mise à l'essai (ou un document de ce genre) fait état des méthodes de contrôle nécessaires pour respecter les exigences énoncées dans le rapport sur le contrôle de gestion du système.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.

5. Étape de mise en oeuvre

Le système en cours d'élaboration est mis en oeuvre dans des systèmes informatisés et manuels devant être opérationnels lors de l'étape suivante, d'après les spécifications de l'analyse des systèmes documentées dans les étapes précédentes.

Des programmes informatiques et des procédures manuelles sont rédigés et testés. Des documents de formation et le calendrier de mise en place sont préparés.

Points concernant le contrôle des activités liées au projet (A)

On doit avoir surveillé la performance du projet pendant l'étape de mise en oeuvre, par rapport aux plans et aux budgets établis lors de l'étape de faisabilité (ou leurs révisions subséquentes), et justifié les écarts auprès des autorités de projets.

Les tests des systèmes et programmes doivent être complets et entièrement documentés. Les problèmes rencontrés doivent avoir été réglés. Le vérificateur peut choisir de réexécuter certains tests de façon sélective, mais ne doit jamais être perçu comme étant responsable des tests.

Les manuels d'utilisations, les formats des entrées et des sorties, la présentation sur l'écran et toute autre forme d'interface avec l'utilisateur doivent être conçus pour optimiser leur efficacité.

Risques principaux

Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :

  • Il peut ne pas y avoir eu de préparation suffisante pour l'emplacement. Le vérificateur doit veiller à ce que la mise en place des lignes de télécommunications, la livraison du matériel et la préparation de l'emplacement n'aient pas été compromises du fait que la date de mise en place coïncide avec l'expiration des ressources budgétaires.
  • Des plans de formation peuvent ne pas avoir été élaborés et partagés avec les utilisateurs de façon adéquate.
  • Le personnel des systèmes peut ne pas comprendre complètement les besoins des utilisateurs.
  • La documentation de l'analyse des systèmes, programmes ou dialogues, et des manuels d'utilisation peut être insuffisante.
  • Les tests peuvent être insuffisants par suite des contraintes de temps ou d'autres contraintes s'appliquant aux ressources.

Objectif

5.A Déterminer si tous les formulaires, manuels, programmes et documents de formation appropriés ont été préparés à partir des spécifications détaillées de la conception.

Critères

5.A.1 Tous les manuels et autres documents requis ont été préparés avant l'installation du système.

5.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que les manuels et les documents requis renferment des données complètes et précises.

5.A.3 Le rapport sur la mise à l'essai (ou un document de ce genre) fait état des résultats obtenus.

5.A.4 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la mise à l'essai renferme des données précises et complètes.

5.A.5 Toutes les ressources humaines nécessaires restent affectées à la réalisation du projet.

5.A.6 Le calendrier des réunions du comité directeur (ou un document de ce genre) indique la date de toutes les réunions prévues, ainsi que les questions qui seront à l'ordre du jour.

5.A.7 Le rapport sur la mise en oeuvre (ou un document de ce genre) examine le projet par rapport au budget et au calendrier établis durant l'analyse détaillée.

5.A.8 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la mise en oeuvre renferme des données précises et complètes, et s'ils approuvent ce rapport.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.

Intégration au système des contrôles de la validité des données (B) et des opérations du système (C)

Des contrôles sont intégrés au nouveau système, lors de cette étape, pour assurer l'intégrité des données et la gestion des systèmes. Les efforts principaux du vérificateur portent surtout sur la vérification des tests, traitée dans la partie qui précède, mais il existe maintenant une possibilité de réexécution sélective des tests pour les contrôles clés.

L'appendice I présente des documents de référence pour la détermination des techniques appropriées permettant de tester à nouveau les contrôles choisis, d'après la nature du système et son environnement. Les systèmes en direct à temps réel, faisant appel à des systèmes de gestion des bases de données sous le contrôle d'une gestion administrative des données séparées, exigeront de nouveaux tests plus complexes que les systèmes typiques à entrées par lots, ou à fichier maître sur bande magnétique. Le recours judicieux aux documents de référence permettra au vérificateur ayant une expérience suffisante en informatique d'exécuter de nouveaux tests efficients et efficaces.

Risques principaux

On doit intégrer au plan de vérification des activités qui tiennent compte des risques principaux suivants :

  • Si le vérificateur se fie totalement à une vérification des documents produits par l'équipe de projets pour les tests qu'elle a effectués, il pourrait en résulter des jugements erronés quant au caractère complet et exact de ces tests.
  • Il est possible que le vérificateur consacre une partie de ses efforts à de nouveaux tests sur les contrôles qui sont en cours de reprogrammation. On devra donc veiller à déterminer le degré de stabilité du système de tests avant de réexécuter des tests de contrôle choisis.

Objectif

5.B Déterminer si les principaux contrôles de transmission sont efficaces.

Critère

5.B.1 Exercer de nouveau certains contrôles de la validité des données.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.

Objectif

5.C Déterminer si les principaux contrôles exercés sont efficaces.

Critère

5.C.1 Exercer de nouveau certains contrôles de la validité des données.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.

6. Étape de mise en place

Lors de cette étape, le système devient opérationnel. La formation commence et les fichiers sont convertis.

Le système est mis en place d'après le plan élaboré lors de l'étape précédente, ce qui peut exiger un processus échelonné, p. ex. par emplacement géographique, par composante organisationnelle ou en fonction des besoins. Dans le dernier cas, la fixation de critères serait nécessaire. Une signature d'acceptation est demandée à l'utilisateur.

Points concernant le contrôle des activités liées au projet (A)

On doit avoir surveillé la performance du projet pendant l'étape de mise en place, par rapport aux plans et budgets établis lors de l'étape de faisabilité (ou leurs révisions subséquentes) et justifié les écarts auprès des autorités du projet.

La conversion des données doit être exacte. Les tests du processus de conversion des données doivent être bien documentés. D'après la qualité et l'exécution des tests exécutés par l'organisme vérifié, le vérificateur peut décider de réexécuter certains tests.

Risques principaux

On doit envisager, lors de cette étape de vérification, des activités portant sur les risques clés suivants :

  • Conversion des fichiers inexacte ou incomplète.
  • Formation du personnel insuffisante.
  • Mauvaise gestion du passage de l'ancien au nouveau système.
  • Fonctionnement des systèmes défectueux, par suite d'une formation incomplète et (ou) d'une participation inefficace de l'utilisateur pendant les tests d'acceptation.
  • A mesure qu'approche la fin de l'année financière ou de tout autre genre de contrainte de calendrier, de temps ou d'argent, la formation, les tests et le contrôle des projets sont assujettis à des tensions négatives qui affectent les réactions de l'équipe de projets aux recommandations de vérification provenant des étapes antérieures.
  • Il est possible qu'il n'existe pas de plan d'urgence testé à la disposition des opérateurs du système.

Objectif

6.A Déterminer si le système et la conversion de fichiers (le cas échéant) passent du stade de développement au stade d'opération et d'entretien.

Critères

6.A.1 La précision, l'intégralité et l'authenticité des fichiers créés par voie de conversion sont assurées grâce à l'application des méthodes de contrôle appropriées.

6.A.2 La formation a été assurée conformément au calendrier préparé à cet effet.

6.A.3 L'installation a été effectuée conformément au calendrier préparé à cet effet.

6.A.4 Le rapport sur l'installation (ou un document de ce genre) examine le projet par rapport au budget et au calendrier contenus dans le rapport sur l'étape de mise en oeuvre.

6.A.5 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur l'installation renferme des données précises et complètes, et s'ils approuvent ce rapport.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice G qui portent le même nom.

Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun objectif pour les contrôles de la validité des données (B) et les contrôles d'opérations du système (C) à l'étape de la mise en place (6).

7. Étape des activités postérieures a la mise en place

Pendant cette étape, le système sera en opération et sera soumis à des changements systémiques contrôlés afin de fonctionner de façon satisfaisante et selon les besoins courants. On doit préparer un rapport sur le projet, trois à six mois après la mise en place du système, pour indiquer son degré de conformité avec les exigences fonctionnelles des utilisateurs et le degré de conformité aux coûts/avantages prévus.

Questions concernant le contrôle des activités liées au projet (A)

Les activités de vérification lors de cette étape comportent un examen du rapport de suivi et des documents de travail, par rapport à toute la documentation des étapes précédentes, afin d'assurer leur conformité avec le CES et d'attester le l'exactitude et l'intégrité des résultats observés.

Risques principaux

On doit inclure dans le plan de vérification des activités portant sur les risques principaux suivants :

  • on peut ne pas disposer d'un nombre suffisant d'opérateurs qualifiés, de documentation satisfaisante pour le système et les utilisateurs ou de soutien approprié;
  • on peut ne pas disposer de soutien prenant la forme de conseils techniques par « ligne directe », de techniciens de centre d'information, etc.;
  • on peut ne pas disposer de renseignements bien documentés sur les cas d'insuffisance opérationnelle, qui permettraient à la gestion d'en prévenir la répétition.

Objectif

7.A Déterminer si le système est exploité conformément aux objectifs de conception et autres critères d'évaluation, et si les coûts/avantages prévus sont atteints.

Critères

7.A.1 L'installation a été suivie d'un examen et si les résultats ont été communiqués aux membres de la haute direction.

Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice G qui portent le même nom.

Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun objectif pour les contrôles de la validité des données (B) et les contrôles d'opérations du système (C) à l'étape des activités postérieures à la mise en place (7).