Cette page a été archivée.
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 ».
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.
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.
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 :
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.
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.
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.
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.
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 :
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.
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.
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 :
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
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.
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.
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 :
1.A Déterminer si le projet a été lancé officiellement et si des contrôles adéquats sont exercés.
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).
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.
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.
On doit intégrer au plan de vérification des activités liées aux risques principaux suivants :
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.
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 :
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.
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.
On doit intégrer au plan de vérification des activités de vérification liées aux risques principaux suivants :
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.
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.
2.C S'assurer que les contrôles en place assurent le fonctionnement efficient, efficace et économique du système.
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.
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.
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.
Dans le plan de vérification, on doit prendre en considération les risques principaux suivants :
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.
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.
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.
Les activités de vérification intégrées au plan de vérification doivent tenir compte des risques principaux qui suivent :
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.
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.
3.C Déterminer si le système fonctionnel est exploité de façon efficace et efficiente.
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.
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.
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.
Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :
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.
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.
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.
On doit intégrer au plan de vérification des activités de vérification qui traitent du risque principal suivant :
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.
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.
4.C Déterminer si le système est exploité de façon efficace et efficiente.
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.
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.
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é.
Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :
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.
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.
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.
On doit intégrer au plan de vérification des activités qui tiennent compte des risques principaux suivants :
5.B Déterminer si les principaux contrôles de transmission sont efficaces.
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.
5.C Déterminer si les principaux contrôles exercés sont efficaces.
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.
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.
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.
On doit envisager, lors de cette étape de vérification, des activités portant sur les risques clés suivants :
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.
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).
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.
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.
On doit inclure dans le plan de vérification des activités portant sur les risques principaux suivants :
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.
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).