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 Â».




Conseil du trésor du canada bureau du controleur général du canada

Séries 500 guide 507
Guide de vérification des systemes en cours d'élaboration

Manuel de vérification interne
Volume iii
Guide de vérification interne

Ébauche de travail
mars 1991

Le Bureau du contrôleur général (BCG) est un organisme qui offre des services bilingues. Soyez tout à fait à l'aise de communiquer avec nous dans la langue de votre choix.

Rédigé au nom du Conseil du Trésor du Canada Contrôleur général Comité consultatif interministériel de la vérification interne

Ottawa, Ontario
K1A 1E4



Table des matières

Avant-propos

Introduction

L'Environnement du processus d'élaboration des systèmes

Détail du processus d'élaboration des systèmes

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

Annexe A : Grille des entrevues

Annexe B : Programme de vérification de l'étape de lancement du projet

Annexe C : Programme de vérification de l'étape de l'étude de faisabilité

Annexe D : Programme de vérification de l'étape de conception générale

Annexe E : Programme de vérification de l'étape de conception détaillée

Annexe F : Programme de vérification de l'étape de la mise en oeuvre

Annexe G : Programme de vérification de l'étape de la mise en place

Annexe H : Programme de vérification de l'étape des activités postérieures à la mise en place

Annexe I : Bibliographie

Annexe J : Politiques et normes du CT et du BCG applicables aux systèmes en cours d'élaboration




Avant-propos

Ce guide a été produit par la :

Direction de la vérification et de l'examen
Bureau du Contrôleur général

Il se fonde sur les documents qui y sont mentionnés ici, de même que sur l'expérience et les idées des participants suivants :

  • Direction de la politique administrative, SCT
  • Direction des vérifications de l'information et de la gestion, Groupe des services de vérification, Agence gouvernementale de consultation et de vérification
  • Direction de l'informatique et des systèmes de gestion
    financière, BCG
  • Vérification de la gestion et évaluation, Travaux publics Canada
  • Directeur général - Vérification, Défense nationale
  • Vérification interne et Évaluation, Revenu Canada - Impôt

 




Introduction

Historique

A la fin de l'année 1983, le Bureau du Contrôleur général décidait, par suite de l'importance des premiers résultats obtenus par le groupe de travail sur l'informatique, de suspendre la publication de la version préliminaire du Guide de vérification de la performance de l'élaboration des systèmes. Le groupe de travail avait été établi par le Conseil du Trésor le 7 juillet 1983 et l'on avait alors pensé que ses activités s'étendraient sur la période des 12 à 18 mois suivants. Cependant, cette période a vu la parution d'une Notice d'interprétation de la politique (NIP 1984-03) sur la « Vérification avant la mise en oeuvre ». C'est sur cette NIP que se fondent l'objet et la portée de ce guide.

Le rapport du groupe de travail a été publié en 1985 et le 22 juillet 1986 une première rédaction de l'Aperçu de la politique de gestion de l'information a été publiée par la Direction de la politique administrative du Secrétariat du Conseil du Trésor, en partie en réponse à ce rapport. Ces différents documents, tout en brossant un portrait clair des changements spectaculaires intervenus dans la technologie de l'élaboration des systèmes, soulignent aussi l'importance du contenu de la NIP au sujet de la vérification de l'élaboration des systèmes. Dans la NIP, il est dit que :

« les vérifications avant la mise en oeuvre doivent être effectuées pour les principaux systèmes en cours d'élaboration dans les ministères et organismes; de plus, elles doivent se refléter dans les politiques et les plans de vérification interne des ministères et organismes; enfin, la possibilité d'un manque d'objectivité de la part du vérificateur peut être minimisée par l'établissement d'un mandat approprié et d'une stratégie de mission adéquate ».

Cet exposé tient donc compte de l'importance revêtue par le contrôle de la gestion sur les systèmes en cours d'élaboration, grâce au processus de vérification.

Objet du guide

L'objet de ce guide est de permettre à un vérificateur interne principal de procéder à une vérification des systèmes en cours d'élaboration. Ce genre de vérification se définit ainsi :

« Examen et évaluation, à différentes étapes du cycle d'élaboration des systèmes, d'un système choisi ou d'une amélioration apportée sur une grande échelle à une application existante. La vérification comporte un examen de la conformité à des aspects spécifiés du processus d'élaboration des systèmes, pour un ministère donné, ainsi qu'un examen des contrôles qui sont intégrés au système, pour assurer que les données à traiter soient complètes et exactes, en respectant les normes de sécurité, d'autorisation et de vérification qui s'y appliquent. »

Tout vérificateur devrait savoir que, dans le cadre d'une vérification de la technologie de l'information, les points à évaluer, outre les systèmes en cours d'élaboration eux-mêmes, sont le centre d'informatique, les activités postérieures à la mise en oeuvre, le fonctionnement du système, le dictionnaire de données, l'informatique individuelle, la sécurité des données et leur gestion, l'acquisition et la gestion de la technologie de l'information, ainsi que la possibilité de nombreux autres genres d'activités de vérification ayant souvent des répercussions sur les questions qui sont du ressort d'une vérification des systèmes en cours d'élaboration. Ces points ne sont pas des objectifs, mais des questions à examiner.

Les objectifs d'une vérification de ce genre sont énoncés comme suit dans la NIP 1984-03 :

  1. La vérification du processus de gestion des projets et d'élaboration des systèmes.
  2. Les produits sont fonction du cadre de contrôle, qui est conçu parallèlement au système en cours d'élaboration, ou qui en constitue une partie intégrante.

Organisation

Le chapitre 1 de ce guide traite de l'environnement de l'élaboration des systèmes dans la fonction publique d'aujourd'hui.

Le chapitre 2 donne une description et un modèle du cycle d'élaboration des systèmes, ainsi que des rôles et des responsabilités des principaux intervenants.

Le chapitre 3 indique les objectifs et les critères d'une vérification des systèmes en cours d'élaboration, en se rapportant au contrôle, à l'économie, à l'efficience et à l'efficacité opérationnelle pour chacune des étapes du processus. Ce chapitre traite tout d'abord des cinq principales activités de la vérification et de la façon dont ces activités se rattachent à chacune des sept étapes du cycle d'élaboration des systèmes. Chacune des parties qui suivent dans le chapitre trois traite des objectifs de projet, d'intégrité des données et de contrôle de la gestion des systèmes pour chaque étape du cycle.

L'appendice A renferme un tableau des personnes à interviewer pour chaque critère détaillé, et les appendices B à H, les critères détaillés pour chaque étape du CES, du lancement aux activités postérieures à la mise en place.

Pour terminer, l'appendice I présente une bibliographie, et l'appendice J, une liste des politiques et normes pertinentes du Conseil du Trésor.

La valeur du processus d'élaboration des systèmes

Comme l'indique la Notice d'interprétation de la politique 1984-03 portant sur la vérification avant la mise en oeuvre :

« les systèmes ainsi mis en oeuvre ne répondent pas toujours, loin de là, aux besoins des utilisateurs; les cadres de contrôle des systèmes, en particulier des systèmes informatisés, ne sont souvent pas suffisamment élaborés; et les récents programmes de réduction, (...) ont fait ressortir le besoin d'accroître la productivité et l'efficacité de tous les processus. Le processus d'élaboration des systèmes fait donc l'objet d'un intérêt tout particulier en raison des effets néfastes et fort coûteux pouvant découler d'une analyse et d'une mise en oeuvre inadéquates. »

Lorsque l'on prend en considération l'investissement que représente l'élaboration des systèmes et le degré de dépendance des ministères vis-à-vis des systèmes pour la gestion et la prestation de leurs programmes, on perçoit clairement tout l'avantage que procurent à la gestion des avertissements opportuns signalant toute défaillance dans l'élaboration des systèmes. C'est pourquoi l'existence d'un cycle officiel d'élaboration des systèmes pour un ministère donné assure la présence de normes essentielles qui permettent d'établir un contrôle de la gestion sur des projets particuliers ou sur des améliorations importantes qui ont été apportées.

Rapports sur les progrès de la vérification de l'élaboration des systèmes

La vérification d'un système en cours d'élaboration doit avoir lieu parallèlement à l'analyse du système, et non pas après sa mise en oeuvre. Par ailleurs, si le concepteur du projet est rapidement informé des constatations de la vérification, il pourra plus facilement apporter les correctifs qui s'imposent. Il est de toute évidence que, plus la vérification est effectuée tôt dans le cycle d'élaboration, plus les solutions apportées aux faiblesses dans l'analyse ou à la gestion de projet sont efficaces. C'est pour cette raison que des méthodes détaillées ont été fournies au début du chapitre 3, à la rubrique « Aspects particuliers en matière de rapport ». (Voir la figure 1)

Aspects particuliers

La vérification des systèmes en cours d'élaboration se différencie des vérifications portant sur le fonctionnement du système et les activités postérieures à la mise en place par le fait qu'elle permet de « revoir » l'élaboration du même système jusqu'à sept fois. Ainsi, une grande partie du travail accompli dans les étapes initiales du processus d'élaboration devient un point de départ pour la vérification des étapes plus tardives de l'élaboration. Le chapitre 3 a été rédigé à la lumière de cette caractéristique.

Le vérificateur doit déterminer si les activités du projet permettent de communiquer efficacement les incidences du projet sur les ressources humaines et si des mesures sont prévues pour traiter de ces incidences. Cet aspect particulier est étudié de façon plus détaillée au début du chapitre 3 et des objectifs de contrôle ont été intégrés au cycle de contrôle des activités liées au projet (A).

Le vérificateur doit également déterminer, au tout début du processus d'élaboration, si le projet tient compte de la planification stratégique du ministère et s'il est directement lié aux objectifs de la haute direction. Les objectifs de contrôle des activités liées au projet (A) (chapitre 3) ont été prévus à cette fin.

Le vérificateur devrait songer à recommander la technique de vérification et de corroboration fondée sur l'évaluation du risque si les chargés du projet ne l'utilisent pas déjà. Le chapitre 3 renferme plus de précisions à ce sujet.

On peut s'interroger sur l'objectivité du vérificateur dans son travail portant sur le fonctionnement du système à une date ultérieure, du fait qu'il participe au renforcement des contrôles, tout au début. Ce point est traité de façon détaillée plus loin dans le rapport, mais on peut déjà affirmer que l'affectation de vérificateurs différents à la vérification portant sur le fonctionnement du système devrait régler le problème (voir le renvoi à la NIP 1984-03 à la page 1).

Figure 1: Le coût du changement

Le coût du changement

 




L'Environnement du processus d'élaboration des systemes

Introduction

Ce chapitre présente quelques définitions et descriptions fondamentales des facteurs internes et externes affectant le processus d'élaboration des systèmes dans le gouvernement. Son objectif est d'offrir une définition uniforme des termes utilisés dans la description des systèmes, ainsi que de spécifier les facteurs considérés comme importants par les vérificateurs dans l'examen d'un système.

Le chapitre est agencé comme suit :

  • définitions
  • facteurs importants :
    • infrastructure de gestion du ministère
    • politiques et normes du cycle d'élaboration des systèmes (CES)
    • processus de planification et d'acquisition
    • processus technologiques
    • politiques des organismes centraux
    • exigences en matière de services communs
    • sécurité et protection des renseignements personnels

Définitions

a) Cycle d'élaboration des systèmes (CES)

Il s'agit là d'une approche structurée qui divise un projet de systèmes d'information en étapes distinctes qui sont suivies par des points de décision et des approbations clés. Ceci permet une évaluation ordonnée du problème à résoudre, un processus ordonné d'analyse et d'élaboration, et une mise en oeuvre ordonnée de la solution. Une étape finale permet une rétroaction de la gestion et le contrôle de celle-ci sur toute l'évaluation postérieure à la mise en oeuvre.

b) Méthodologie d'élaboration des systèmes

Il s'agit là de l'adaptation du CES à un ministère donné, qui peut être un ensemble interne de procédures, de formules et de processus pour chaque étape habituelle du CES, ou bien encore un ensemble commercial de logiciels, de procédures, de formules et de processus jugés plus efficaces par le ministère.

c) Projet d'élaboration des systèmes

Il s'agit là d'activités nécessaires pour répondre aux exigences de la méthodologie particulière d'élaboration des systèmes qui est suivie, afin d'atteindre un ensemble d'objectifs ou de résoudre certains problèmes. Ces activités sont menées par une équipe travaillant sous la direction d'un gestionnaire de projet, qui devrait exécuter toutes les activités CES normales de gestion pour la réalisation du projet.

L'environnement de l'élaboration de projets

On a assisté, au cours des années 1980, à une accélération des changements dans la complexité de l'environnement informatique. Non seulement la complexité des activités se rapportant à l'élaboration des systèmes s'est-elle accentuée, mais aussi l'éventail des fonctions intégrées à l'analyse et à l'élaboration des systèmes. Ces changements dans la complexité et l'éventail des fonctions ont été en outre multipliés par une tendance de l'« utilisateur final » à créer des systèmes.

Nous continuerons à voir augmenter l'utilisation des langages de quatrième génération (L4G), la création de prototypes, les mises en oeuvre pilotes et les instruments des logiciels d'étude des systèmes assistée par ordinateur. Dans chaque cas, la vérification interne devra rajuster son approche, mais les principes fondamentaux exposés dans le présent guide demeureront. Les modifications futures du guide traiteront directement de ces progrès récents liés à la méthodologie d'élaboration des systèmes.

Ces tendances ne feront qu'augmenter à l'avenir.

Les vérificateurs internes doivent donc se tenir au courant des facteurs de l'environnement, internes et externes, qui exercent une influence sur le processus d'élaboration des systèmes. La figure 1.1 ci-après et les descriptions qui suivent illustrent ces facteurs.

Figure 1.1 : Cycle d'élaboration des systèmes

Cycle d'élaboration des systèmes

Descriptions des facteurs généraux

Infrastructure de gestion du ministère

Le premier domaine à prendre en considération est l'organisation générale du ministère et son infrastructure pour l'élaboration des systèmes. On s'intéressera particulièrement aux rôles et responsabilités de l'organisme (ou des organismes) chargé de la gestion de l'information, aux comités directeurs consultatifs ou se rapportant aux utilisateurs, ainsi qu'aux principaux comités de gestion du ministère.

Le vérificateur doit s'assurer du degré de coordination entre ces organismes et vérifier leurs réalisations antérieures. Ces renseignements permettront d'avoir un certain nombre d'« indices » quant aux questions ou secteurs d'enquête pouvant se présenter et de connaître l'étendue de la participation antérieure de l'utilisateur, ainsi que de vérifier jusqu'à quel point les gestionnaires ont su élaborer des systèmes efficaces dans le cadre des contraintes de temps et de coût.

Politiques et normes du CES

Un deuxième facteur important qui influence l'élaboration des systèmes est l'ensemble des politiques et normes du CES du ministère. Cet ensemble constitue en effet la base de l'élaboration des systèmes; sa raison d'être est de souligner la définition des exigences avant le début de l'étape de conception, ce qui permet de réduire au minimum les modifications coûteuses qui pourraient s'imposer plus tard dans le cycle d'élaboration.

Le vérificateur interne doit, par conséquent, examiner les politiques et les normes du ministère afin de s'assurer, de façon continue et pendant toute la participation au CES, que le projet d'élaboration satisfait bien aux exigences du ministère.

Processus de planification et d'acquisition

Le plan de gestion de l'information (qui découle du plan des systèmes et des techniques d'information (PSTI)) et le budget des immobilisations sont la troisième source principale d'information pour le vérificateur. Ces deux documents de planification sont préparés en tant qu'éléments du plan opérationnel pluriannuel (POP) du ministère.

Bien que le nom et le contenu du processus exigé par le SCT (l'ancien PSTI) aient changé depuis la première édition du présent guide, le principe que le vérificateur doit tout connaître de la planification stratégique, tactique et opérationnelle du ministère, pour assurer les hauts fonctionnaires que le projet appuie ces initiatives de planification, demeure valide.

Le PSTI tient compte des plans informatiques, à la fois pour les activités en cours et pour les nouvelles initiatives, ainsi que de l'affectation des ressources nécessaires à la réalisation des stratégies, des politiques et des programmes relatifs à l'informatique. Le PSTI tient également compte du budget des immobilisations prévu pour les nouvelles acquisitions en informatique.

En outre, l'élaboration doit être conforme aux politiques et procédures des organismes centraux (voir le chapitre 1 - Politiques et procédures des organismes centraux).

Le vérificateur interne doit examiner le PSTI et le budget des immobilisations afin d'établir le lien qui convient entre ces documents de planification et le système particulier qui est en cours d'élaboration. En outre, il est important que le vérificateur s'assure que la planification établie pour le projet d'élaboration des systèmes est reliée au processus d'acquisition en informatique du ministère et est coordonnée avec celui-ci.

Tendances de la technologie dans la fonction publique

L'ensemble des tendances de la technologie ayant une répercussion sur la gestion de l'information dans la fonction publique constitue le premier facteur externe à influencer fortement la façon dont le vérificateur perçoit l'élaboration des systèmes. L'« Aperçu de la politique de gestion de l'information - Orientation stratégique en matière de gestion de la technologie de l'information dans le gouvernement fédéral », publié par le Conseil du trésor en 1987 signale que :

« La gestion des systèmes d'information en fonction d'une approche se fondant sur les cycles d'élaboration connaîtra une importance plus grande dans le gouvernement, compte tenu, dans un cadre de responsabilité accrue pour les ministères, des investissements opérés dans les systèmes, des avantages reçus et de la nécessité de planifier le remplacement des systèmes. »

Cet aperçu présente également une évaluation intéressante de la situation actuelle et il convient de noter que chacun des principes énoncés s'applique à la vérification des systèmes en cours d'élaboration :

« Les politiques actuelles sur l'informatique et les télécommunications s'appuient sur des principes toujours valables :

  • les ressources sont utilisées pour appuyer les programmes du gouvernement et ne constituent pas une fin en elles-mêmes;
  • c'est le secteur privé qui répond aux besoins du gouvernement, sauf lorsqu'il s'agit de l'intérêt public ou qu'il est plus économique de fournir les services de façon interne;
  • les ministères élaboreront des plans annuels contenant de l'information sur les projets, l'équipement et le personnel, et ces plans découleront de plans à plus long terme;
  • des efforts seront faits pour cerner les possibilités de partage de plans d'information, de l'information elle-même et des compétences qui s'y rapportent;
  • les ministères établiront leurs propres politiques internes;
  • l'approbation des projets d'élaboration des systèmes se fera par étapes;
  • la politique sur les micro-ordinateurs permettra de prendre également en ligne de compte l'incidence sur les personnes et la nécessité d'une formation. »

L'aperçu continue en esquissant les réajustements qu'il faut opérer dans la portée de l'élaboration des systèmes et qui sont rendus nécessaires par la complexité accrue de l'environnement :

« Il faut cependant des réajustements dans les politiques d'information du gouvernement pour tenir compte du fusionnement des technologies de l'information, des facteurs se rapportant aux ressources humaines et des développements récents, ainsi qu'il a été noté plus haut. On devra également, dans les mises à jour futures des politiques, s'occuper de facteurs tels que le besoin d'assurer une qualité et une cohérence des données à l'échelle des ministères et du gouvernement dans un environnement où une puissance informatique plus grande est donnée aux utilisateurs. »

La lecture complète de l'aperçu révèle, en résumé, que le domaine de l'élaboration des systèmes a été élargi, et continuera à l'être. Voici les facteurs contribuant à ce phénomène :

  • l'importance de la qualité et de la cohésion des données,
  • la capacité de traitement à la disposition de l'utilisation,
  • la complexité et l'interactivité des systèmes,
  • l'existence, le cas échéant, de meilleurs « instruments » d'élaboration, tels que la création de prototypes, les langages de la quatrième génération, les logiciels d'étude des systèmes assistée par ordinateur et les logiciels de bases de données interactives (avec des dictionnaires de données actifs),
  • une augmentation, et non une réduction, des fonds à investir pour le remplacement des systèmes,
  • les questions critiques de ressources humaines en informatique,
  • l'inclusion ou l'intégration des télécommunications.

Politiques et procédures des organismes centraux

Il existe deux organismes ayant une incidence sur la façon dont les systèmes sont élaborés dans la fonction publique : la Direction de la politique administrative du Secrétariat du Conseil du Trésor (SCT) et la direction de l'Information et des systèmes de gestion financière du Bureau du Contrôleur général (BCG). La législation a prévu pour ces organismes un rôle directeur dans la gestion et le contrôle de la technologie de l'information. Dans ce rôle, ils ont créé un fonds de politiques administratives, de directives et de lignes directrices connexes qui constituent une stratégie d'orientation et un cadre global que les ministères et les organismes doivent respecter.

La Direction de la politique administrative a élaboré et promulgué des politiques et des directives qui traitent de tous les aspects du cycle de l'information et du CES, tels que la gestion de projets, l'accès à l'information, les services communs, la micrographie, l'informatique, les télécommunications et les micro-ordinateurs.

Cette Direction examine également les plans de gestion de l'information (PGI) soumis par les ministères et organismes et prépare un examen annuel de la technologie et des systèmes d'information utilisés par le gouvernement fédéral. Le paragraphe 1.A.1.2 du chapitre 3 recommande que le vérificateur détermine si le projet est bien intégré aux plans du ministère.

La Direction de l'information et des systèmes de gestion financière (DISGF) encourage l'élaboration de pratiques et de contrôles de gestion solides au sein du gouvernement et surveille leur mise en oeuvre. Pour aider les employés chargés de mettre en place les systèmes financiers, la Direction a fait publier des principes directeurs, des critères et des politiques portant sur l'élaboration des systèmes financiers; elle continue d'en élaborer. L'appendice J (points 13 à 18) renvoie à ces aides en matière d'élaboration des systèmes financiers. Il est très important que les vérificateurs se tiennent au courant de ces critères et normes, au fur et à mesure qu'ils sont publiés, car ils feront partie de l'examen des contrôles que le vérificateur effectuera au moment de l'élaboration des systèmes financiers.

La Direction est également responsable du rôle du BCG dans la stratégie en matière de gestion financière qui commence à apparaître. La référence 19 de l'appendice J décrit cette entreprise commune du BCG et de ASC. A ce stade, il suffit de dire que le vérificateur doit connaître la stratégie et savoir comment elle s'applique aux stratégies ministérielles relatives aux systèmes financiers en voie d'élaboration.

Les vérificateurs devraient également être au courant des négociations de leur ministère dans le cadre du régime d'accroissement des pouvoirs et des responsabilités ministériels (APRM) ainsi que des répercussions de ces négociations sur les systèmes financiers en voie d'élaboration. Le Bureau du contrôleur général est le point de référence pour toutes les questions relatives aux exigences en matière de rapport de l'APRM.

Exigences en matière de services communs

La nature et la portée des services communs sont décrites au chapitre 303 du Manuel de la politique administrative du Conseil du Trésor, ainsi que dans une série de directives. Les services communs forment un élément important dans les opérations informatiques et leur gestion. Le chapitre 303 précise à ce sujet : « Le gouvernement a pour politique de fournir des biens et des services par des organisations de services communs en vue d'obtenir la valeur maximale en contrepartie de l'argent dépensé et d'assurer l'observation plus uniforme de décisions de politique socio-économique et un respect plus poussé des exigences en matière de prudence et de probité ». Le fait que les services communs s'étendent à tout le gouvernement leur donne les caractéristiques d'un service central. Cela peut exercer une influence importante sur les pratiques de gestion de la technologie de l'information et l'élaboration des systèmes dans le gouvernement.

Le vérificateur doit donc déterminer si la gestion a considéré l'incidence des exigences en matière de services communs (ainsi les services de salaires et pensions, les services d'achat, les services assurés par ASC, TPC, Communications, la BNC (Archives) et les autres services assurés par différents ministères) dans sa stratégies de planification.

Sécurité et protection des renseignements personnels

La question de la sécurité et de la protection des renseignements personnels au sein de l'environnement de la technologie de l'information a reçu beaucoup d'attention depuis quelque temps, en particulier de la part de la Direction de la politique administrative du Secrétariat du Conseil du Trésor. Le Conseil a publié les documents suivants : Politique du gouvernement du Canada sur la sécurité (révisée en septembre 1987), Sécurité au gouvernement du Canada - Normes provisoires de sécurité : Directives et lignes directrices d'utilisation (1987) et la circulaire 1987-52 du SCT, Examen de la mise en oeuvre de la politique sur la sécurité. On se rapportera à l'appendice J pour une liste de documents complémentaires.

Bien que certains des documents de référence qui suivent ne soient plus à jour, ils peuvent renfermer des renseignements utiles. Le vérificateur doit examiner tout particulièrement le Manuel de la politique administrative de d'autres publications, particulièrement :

  • la Politique et les normes en matière de sécurité du gouvernement du Canada (en vigueur);
  • l'ébauche du Guide de la vérification de la sécurité du BCG (en vigueur);
  • les normes provisoires sur la technologie de l'information (IIIe partie des Normes provisoires de sécurité);
  • les mesures en cas d'urgence, GES/NE1-14 - 4.1.2.7;
  • les plans en cas de désastre, 4.1.2.7.3;
  • la sécurité des logiciels, 4.6;
  • l'assurance de la conception, de l'élaboration et de la qualité, 4.6.2.

La sécurité et la protection des renseignements personnels doivent idéalement être envisagées par le vérificateur à chaque étape du processus d'élaboration des systèmes, bien que toutes les exigences pertinentes à la sécurité et à la protection des renseignements personnels doivent être prises en ligne de compte dès le début du projet, en déterminant alors la personne qui assume les responsabilités de coordonnateur de la sécurité en informatique et d'agent de la sécurité pour le ministère. On doit également déterminer au début de la vérification que l'on peut effectivement disposer des rapports pertinents établis par l'équipe d'évaluation et d'inspection de la sécurité de la GRC.

 




Détail du Processus d'élaboration des systemes

Introduction

Ce chapitre décrit le cycle d'élaboration des systèmes, ainsi que les rôles joués dans ce cycle, de façon suffisamment détaillée pour permettre aux vérificateurs de procéder à une vérification de l'élaboration, à n'importe quelle étape du cycle d'élaboration (CES) telle qu'intégrée par un ministère à son propre processus d'élaboration des systèmes (PES). Cela signifie que le vérificateur devrait être en mesure d'évaluer les progrès du projet, de comparer les réalisations tangibles à celles jugées normales par le présent guide pour l'étape d'élaboration à l'étude. Ainsi, il devrait pouvoir situer le projet par rapport à la norme. Le vérificateur pourra alors choisir, parmi les objectifs de vérification donnés à ce stade du CES normal, les objectifs qui s'appliquent au projet donné.

Le cycle d'élaboration des systèmes

La politique sur la « Gestion des technologies de l'information » diffusée en juin 1990 par le Conseil du Trésor remplace le chapitre 440.3 (Appendice J du présent guide) du Manuel de la politique administrative du Conseil du Trésor (1978). Le chapitre 440 définissait le cycle d'élaboration des systèmes sur lequel se fondait le présent guide. Même si le Conseil du Trésor n'impose plus un CES en particulier, le présent guide demeure valable pour ce qui est de définir la vérification d'un CES conforme aux pratiques acceptées d'élaboration des systèmes.

Le but d'un CES est de permettre aux concepteurs et aux utilisateurs de produire un système contrôlé, économique, efficient et efficace. Les étapes du processus d'élaboration qui suivent ont été suggérées par le Conseil du Trésor (MPA, 1978, Ch. 440) :

  • 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

Même si le CES conventionnel consiste en un cycle à sept étapes, les CES particuliers de ministères peuvent en comporter plus ou moins. Par contre, à partir du travail contenu dans chaque étape ou combinaison d'étapes d'un CES, on peut mesurer le progrès en établissant des liens avec la norme en matière de réalisation des sept étapes (voir la figure 3). Par conséquent, comme il a été mentionné précédemment, les objectifs et les critères de vérification présentés au chapitre 3 peuvent être choisis pour la vérification d'un système donné parmi les objectifs chronologiques du présent guide qui s'appliquent à la phase de vérification en question ou à des phases antérieures.

De même, une école de pensée veut actuellement que, à une époque de micro-ordinateurs, de création de prototypes ou de langages de la quatrième génération, les organismes ne puissent se permettre les contraintes d'une méthodologie officielle s'appliquant au cycle d'élaboration. Néanmoins, il incombe aux vérificateurs d'assurer l'existence de points valables pour le contrôle de la gestion, quel que soit le cycle particulier en place. A ces fins, le contenu ou les produits des étapes d'élaboration, qui devront avoir eu lieu dans la séquence logique du CES conventionnel, sont essentiels.

Création de prototypes

Avant que l'on procède à l'établissement d'un tableau comparatif du CES conventionnel et de le comparer à un autre exemple de terminologie, il convient d'examiner une technique d'élaboration récente.

La création de prototypes appliqués est définie dans le présent guide comme un modèle visuel dynamique qui constitue un instrument de communication pour les utilisateurs ou les responsables de l'élaboration des systèmes, d'une efficacité supérieure à celle de la simple prose ou des modèles visuels statiques lorsqu'il s'agit de décrire la fonctionnalité. Il s'agit d'une approche qui doit simuler le système final et cette technique vient s'ajouter à une méthodologie de gestion, qu'elle ne remplace pas. S'il a été clairement décidé d'adopter cette technique, la création de prototypes doit être utilisée lors des étapes de faisabilité et de conception générale afin de déterminer les exigences fonctionnelles et les exigences en matière de données, en permettant la participation des utilisateurs par une expérience pratique aussitôt que possible dans le cycle. Le vérificateur doit, aux étapes de faisabilité et de conception générale, examiner la décision de l'équipe de projets et le contrôle s'appliquant à la création de prototypes, dans le cas où cette technique a été retenue.

Le vérificateur doit veiller à ne pas confondre les prototypes et les essais pilotes. Dans le premier cas, un prototype peut avoir été créé à partir d'un logiciel non productif et, par conséquent, ne jamais devenir opérationnel. L'essai pilote, pour sa part, est conçu pour devenir opérationnel.

Le vérificateur doit veiller à ce que l'équipe comprenne bien la différence entre le prototype et l'essai pilote ou à ce que des décisions officielles aient été prises par les détenteurs du pouvoir d'approbation pour que le prototype puisse passer l'étape de conception générale (ou une étape équivalente).

Gestion des données

Le vérificateur doit être conscient du fait que les ministères ont tendance à gérer leurs données de façon formelle. Il doit également être conscient des répercussions sur l'élaboration des systèmes que peuvent entraîner, dans leur environnement, l'administration des données et l'administration des bases de données. Il pourra consulter comme référence le « Rapport sur la stratégie de gestion de l'information pour les services communs » publié en 1989 par le Comité consultatif sur la gestion de l'information du SCT.

La Figure 2 ci-après illustre un exemple de méthodologie d'élaboration, sous forme d'un graphique de cheminement, pour un environnement qui fait appel à la gestion des données et à des techniques de conception structurées. Il ne s'agit pas de la méthode proposée pour le CES conventionnel, mais la plupart des termes et des produits des étapes sont semblables à ceux utilisés pour le CES conventionnel. En comparant les produits des étapes normalisées aux produits du système en cours d'élaboration qui fait l'objet de la vérification, le vérificateur sera en mesure de choisir, dans le présent guide, les objectifs équivalents de l'étape normalisée. Il disposera donc d'une série d'objectifs, qu'il pourra augmenter selon la nature du système donné, qui lui permettront d'assurer une vérification optimale pendant l'élaboration, quels que soient le CES particulier et les caractéristiques particulières du système.

La Figure 3 (ci-dessous, après la figure 2) présente les produits attendus pour chacune des étapes du CES conventionnel.

Figure 2 : Exemple de cycle d'élaboration des systemes non conventionnel

Exemple de cycle d'élaboration des systemes non conventionnel

Note 1 : Le dictionnaire de données actif permet à l'ordinateur un plus grand contrôle des méta-données (données sur les données dans le système) que le dictionnaire passif.

Figure 3 : CES conventionnel - Produits attendus par étape

Étape Activité Produit
Lancement
  • Demandes de filtrage
  • Détails des documents
  • Planification et approbation
  • Rapport de lancement
  • Définition des problèmes
  • Approche
  • Rôles/Plan du projet
Faisabilité
  • Recueil des données
  • Analyse des données
  • Élaboration de solutions de rechange
  • Évaluation du design conceptuel
  • Rédaction du rapport
  • Rapport de faisabilité
  • Besoins de l'utilisateur
  • Évaluation des systèmes de rechange
  • Design conceptuel
  • Concept
  • Plan du projet
  • Recommandations
Conception générale
  • Recueil des données
  • Analyse
  • Esquisse du système
  • Esquisse des contrôles
  • Assurance qualitative, objectif performance / secondaire
  • Objectifs en matière de sécurité
  • Validation des besoins de l'utilisateur
  • Planification et approbation
  • Rapport de conception générale
  • Coûts/Avantages révisés
  • Spécifications fonctionnelles
  • Contrôles
  • Exigences techniques révisées
  • Plan du projet révisé
  • Plan de conception détaillée
Conception détaillée
  • Conception des sous-systèmes
  • Création des sous-systèmes
  • Conception des aides à l'utilisateur
  • Conception des tests pour le système
  • Conception de la conversion
  • Préparation du rapport
  • Planification et approbation
  • Rapport de conception détaillée
  • Coûts/Avantages révisés
  • Exigences techniques révisées
  • Description du système
  • Procédures pour l'utilisateur
  • Plan du projet révisé
  • Plans de mise en oeuvre et de mise en place
  • Plan de formation
Elaboration
  • Codage des logiciels
  • Tests du système et des unités
  • Production d'aides à l'utilisateur
  • Planification et approbation
  • Rapport de mise en oeuvre
  • Programmes documentés
  • Manuel de prodécure pour l'utilisateur
  • Manuels de formation et d'opérations
Mise en oeuvre
  • Installation des équipements
  • Tests pour les accepter
  • Formation et conversion
  • Opération et approbation
  • Achèvement du projet
  • Avis d'approbation
Activités postérieures à la mise en place
  • Rajustements apportés au système
  • Recueil des données sur  les activités postérieures
  • à la mise en place
  • Rapport d'évaluation

Description des étapes

1. Étape de lancement d'un projet

Les activités exécutées à cette étape doivent être la définition formelle du mandat du projet et l'établissement de ses paramètres de contrôle.

Les procédures à l'égard d'un projet comportent un examen préliminaire du système existant (s'il en existe un) afin d'évaluer la nécessité de changements et la nature de ces derniers. On doit donc définir le « problème ». Une solution potentielle doit être conceptualisée pour servir de référence pendant l'étape d'étude de faisabilité. La solution ne doit pas être décrite trop en détail, cela pouvant nuire aux solutions de rechange examinées lors de l'étude de faisabilité.

A ce moment, on doit déterminer toutes les contraintes externes et internes (coût, temps, législation, lignes directrices du ministère, besoins de l'utilisateur, etc.), et évaluer leur incidence sur le problème et sur la solution qui aura été retenue. On doit également évaluer lors de cette étape la question de la sécurité, y compris les exigences concernant la relance informatique à la suite d'un sinistre, ainsi que les points se rapportant à la protection des renseignements personnels.

Le produit obtenu lors de cette étape consiste en un rapport de lancement du projet.

2. Étape de faisabilité

A la fin de cette étape, on devrait avoir déterminé une solution convenant au problème ainsi qu'un plan préliminaire pour sa mise en oeuvre.

Les exigences de l'utilisateur, qui peuvent être documentées ou établies par la création de prototypes, servent de fondement à la solution retenue.

Il est de la plus grande importance d'étudier suffisamment d'autres approches possibles. Une analyse détaillée des différentes solutions de rechange, au niveau conceptuel, doit appuyer le choix officiel de la solution proposée. Cette analyse doit comporter une analyse coûts/avantages (ou des techniques semblables) et envisager les contrôles financiers et opérationnels, de même que la compatibilité organisationnelle. Comme à l'étape de lancement du projet, on doit s'assurer que les évaluations sont objectives et complètes, et qu'elles ne favorisent pas une solution particulière.

On doit préciser les exigences en matière de ressources pour le reste du projet et procéder à une évaluation du temps et du coût nécessaires, pour leur approbation par la gestion. L'énoncé des exigences réparties entre chacune des étapes du projet, servira à contrôler son élaboration.

Les éléments qui précèdent doivent être documentés dans un rapport de faisabilité.

3. Étape de conception générale

Le travail accompli lors de cette étape transposera la solution conceptuelle proposée, qui aura été déterminée pendant l'étude de faisabilité, en une solution pratique se prêtant à la conception détaillée et à la mise en oeuvre.

Ce travail exigera :

  • la préparation d'une esquisse du système, y compris les graphiques de cheminement, les critères de performance du système, ainsi que la spécification, la définition et le formatage préliminaire de toutes les entrées et sorties, et de tous les fichiers utilisés ou produits par le système; (cela demandera des contacts intensifs avec les utilisateurs.)
  • une vue d'ensemble du cadre de contrôle interne et des procédures de fonctionnement pour que l'on puisse s'assurer qu'elles répondent aux objectifs du système en cours d'élaboration, (le système proposé doit satisfaire à toutes les exigences de l'utilisateur.)
  • la sélection d'installations et de descriptions de tâches pour les fournisseurs ou les façonniers;
  • une esquisse de toutes les spécifications fonctionnelles permettant de s'assurer que la conception générale répond à tous les objectifs du système déterminés.
  • les coûts révisés, les évaluations de temps et les autres critères se rapportant aux étapes à venir, pour leur approbation par la gestion.

La documentation de l'information recueillie lors de cette étape sera normalement incluse dans un rapport sur la conception générale. Il est possible que certains ministères préfèrent préparer deux rapports, dont un pour mettre en évidence la conception du système de gestion lui- même. Dans tous les cas, ces éléments doivent être clairement documentés.

4. Étape de conception détaillée

Des procédures détaillées et des spécifications informatiques sont produites à partir des spécifications fonctionnelles énoncées lors de l'étape de conception générale. Tous les contrôles, procédures, cheminements du travail, documents des entrées et des sorties, logiques de traitement, dispositions des fichiers et des bases de données, ainsi que les éléments de données seront complètement mis au point.

L'approbation de cette étape de conception par la gestion et les utilisateurs est d'une importance capitale. Par conséquent, le produit final de cette étape, le rapport de conception détaillée, doit contenir, outre les spécifications des programmes et les cheminements du travail détaillés, etc., une description non technique de tout le système, qui comprendra :

  • une description du système, des objectifs, des entrées et des sorties;
  • un graphique de cheminement, indiquant le design conceptuel.

Les cadres de gestion concernés doivent examiner les spécifications détaillées, ainsi que les exigences techniques.

On doit également produire, lors de cette étape, des plans documentés d'essai des systèmes, ainsi que des plans de mise en oeuvre et de conversion. En outre, on produira un plan portant sur la façon dont seront coordonnées les activités des étapes de mise en oeuvre et de mise en place, ce qui comportera la préparation de manuels d'instruction (pour les utilisateurs et les opérateurs). On devra également définir les procédures de formation, de sécurité, de sauvegarde et de conversion.

5. Étape de mise en oeuvre

Les activités de cette étape aboutiront à la création de tous les programmes, formules, manuels et documents de formation pour l'informatique nécessaires à un système opérationnel.

Une logique de programmation détaillée sera conçue et des logiciels d'application seront codés.

Les manuels se rapportant à l'utilisation, aux opérations et à la formation seront mis au point et devront, le cas échéant, couvrir les points suivants :

  • la saisie des données
  • la validation des données
  • les pistes de vérification et les mécanismes de contrôle du système
  • la vérification des rapports d'analyse
  • les consignes d'exploitation de l'ordinateur
  • les procédures de sauvegarde et de réexécution
  • les procédures de sécurité

Tous les aspects du système, y compris la logique des programmes et les procédures opérationnelles, doivent être complètement mis à l'essai. De même, toutes les procédures nécessaires à la mise en place du système doivent être définies et faire l'objet d'un calendrier.

6. Étape de mise en place

Lors de cette étape, le système est rendu opérationnel. Le travail comportera la conversion des fichiers existants (s'il y en a) ou la création de la base d'information initiale, la formation convenable du personnel participant au système (utilisateur et informatique), ainsi que l'établissement de procédures de contrôle ou de procédures opérationnelles, par une gradation d'opérations pilotes ou parallèles. Toute la documentation provenant des étapes antérieures doit être finalisée. Les procédures de conversion et de mise en place doivent faire l'objet d'un examen et d'essais. Le gestionnaire de projets doit alors présenter un avis formel d'achèvement du projet pour qu'il soit approuvé.

7. Étape d'activités postérieures à la mise en place

Le travail effectué lors de cette étape consiste en un examen de la performance du projet et de la performance du système par rapport à la documentation de projet originale sur les coûts/avantages du système, ainsi qu'avec le coût du projet et les calendriers.

Un certain délai est normalement alloué entre la mise en place et la vérification postérieure à celle-ci. L'équipe de vérification peut alors être également changée pour maximiser l'objectivité, ce qui réduira par contre l'efficacité de la vérification.

Ainsi, les examens du projet peu de temps après la mise en place d'un système sont importants afin d'évaluer le succès du processus d'élaboration des systèmes et de relever toute différence entre la conception des contrôles et leur fonctionnement.

Conclusion de la description des étapes

Comme on l'a indiqué précédemment, il doit exister des normes adéquates dans les ministères, qui doivent être suivies pour chaque étape de CES afin d'assurer un contrôle cohérent et complet de la gestion sur la mise en oeuvre. Toutefois, il peut être approprié que le ministère ait défini et approuvé un ensemble distinct d'activités de CES se fondant sur le genre de projet qui est en cours (c.-à-d. l'élaboration des systèmes majeurs ou mineurs). Il est normal de documenter l'approbation que la gestion a apportée à toute déviation vis-à-vis des normes du ministère.

Dans de nombreux cas d'élaboration par l'utilisateur final de micro ou de mini-ordinateurs, un examen de l'importance revêtue par les données ou par l'information pour l'organisation peut justifier une partie ou la totalité des points de CES se rapportant aux contrôles.

En évaluant si l'élaboration ou la modification d'un système est assez minime pour justifier le regroupement ou l'élimination de quelques-unes des étapes de CES, le vérificateur doit garder présent à l'esprit le fait que certains changements relativement mineurs peuvent revêtir une importance très grande du point de vue des contrôles.

Rôles

Les descriptions typiques qui suivent illustrent comment chaque étape du modèle de CES fournit à la gestion une assurance de contrôle, d'économie, d'efficacité et d'efficience. Il s'agit de descriptions élémentaires; les vérificateurs peuvent néanmoins s'attendre à rencontrer de telles personnes ou de telles activités dans un environnement contrôlé. Ces rôles, ou leur équivalent, et d'autres rôles figurent à l'appendice A comme des personnes à qui poser les questions liées aux objectifs et critères proposés pour chaque étape de vérification.

Gestion

La gestion doit jouer un rôle d'examen pour assurer que le système élaboré réponde aux objectifs de l'organisme. La gestion assigne des priorités aux projets, aux budgets et aux échéanciers. C'est la gestion qui établit les politiques et les normes du ministère pour l'élaboration des systèmes, puis qui exerce son contrôle sur le processus d'élaboration en s'assurant qu'un CES soit en place et fonctionne d'après son analyse.

La gestion a une responsabilité majeure, soit de décider l'importance du risque pouvant être toléré dans un projet.

Il est possible que la gestion ait besoin de l'aide technique de tiers pour l'aider à assurer ses responsabilités.

Comité directeur ou personnes dotées du pouvoir d'approbation

Chaque organisme gouvernemental nomme en général une personne dotée du pouvoir d'approbation pour chaque étape du processus d'élaboration. Ensemble, ces personnes représentent le pouvoir d'approbation. Certains ministères ont un comité directeur de l'informatique au niveau du SM chargé d'examiner tous les rapports de vérification des systèmes. Ce comité dispose parfois de l'approbation finale. Le point clé dans la vérification interne est de s'assurer qu'il existe sur place la preuve d'un processus d'approbation formel, avec pouvoir de signature à l'échelon des cadres supérieurs.

Concepteur/analyste

Le concepteur/analyste reprend les exigences de l'utilisateur pour élaborer un système répondant aux objectifs et aux besoins de celui-ci. Le concepteur s'assure que toutes les exigences et tous les besoins ont été recueillis, et que l'analyse du système est fonctionnelle. Le concepteur/analyste a également la responsabilité d'un contrôle général du système sur les données qui dépassent ou intègrent les contrôles de programme individuels, et doit choisir la solution d'analyse technique optimale convenant au système. Le vérificateur doit s'assurer que le rôle de contrôle de l'analyste n'est pas compromis par le gestionnaire de projet ou toute autre personne.

Programmeur

Le programmeur est responsable de la création d'un programme efficace et efficient à partir d'une spécification du programme reçue de l'analyste ou du représentant fonctionnel. Le programme peut être un dialogue ou un module du système global et les contrôles figurant dans la spécification doivent permettre de s'assurer que les données conservent leur intégrité tout le long du processus de traitement. Le programmeur voit à mettre en place les contrôles sur les données dans le processus de mise en forme des entrées, dans le traitement informatique interne des programmes, ainsi que dans les sorties affichées, communiquées ou imprimées.

Utilisateurs

C'est l'utilisateur qui doit clairement définir et appuyer les objectifs, les exigences et les besoins auxquels le système doit satisfaire dans les étapes initiales d'élaboration. Il est également de sa responsabilité d'établir les exigences en matière de contrôle technique non informatique et de s'assurer que le système qui en résulte réalise le contrôle demandé. L'utilisateur peut avoir besoin de l'aide technique de tiers pour s'assurer que le contrôle voulu soit en place.

Processus de sécurité dans le ministère

Le chapitre 440 du Manuel de la politique administrative du Conseil du Trésor indique les responsabilités, en matière de sécurité du ministère, de la GRC, du ministère des Approvisionnements et Services, du ministère des Communications, du ministère des Travaux publics et de l'Équipe d'inspection et d'évaluation de la sécurité en informatique. En outre, ce chapitre indique brièvement le rôle de l'agent de sécurité du ministère et du Comité consultatif de la sécurité, dans le cadre des deux activités de coordination et d'administration de la sécurité. Chaque ministère doit fournir, directement ou en consultant l'Équipe d'inspection et d'évaluation de la sécurité en informatique de la GRC, des conseils, des normes et une évaluation des contrôles physiques (et non logiques) nécessaires dans ce ministère pour les données, l'information et les actifs matériels. La délégation de signature, émanant de l'autorité d'approbation, doit être en évidence à chaque étape du projet d'élaboration des systèmes.

Le point 12 de l'appendice J contient d'autres références concernant la sécurité.

Gestionnaire ou administrateur des données dans le ministère

La gestion des données et de l'information acquiert dans de nombreux ministères une importance renouvelée du fait qu'elle constitue un élément d'actif critique. On peut décrire l'administration des données comme regroupant les fonctions de planification, d'administration et de contrôle des données se rapportant aux activités d'un organisme. Le personnel provenant du secteur de la gestion ou de l'administration des données doit être considéré comme membre clé de l'équipe de projet.

Administrateur de la base de données du ministère

L'administration de la base de données regroupe la planification, les décisions, le contrôle et toute autre fonction menant directement aux bases de données opérationnelles, ou ayant une incidence directe sur celles-ci.

Là où il existe une distinction, dans le domaine technique, entre l'analyste et l'administrateur de la base de données, le vérificateur doit s'assurer que ce dernier fait partie de l'équipe de projet.

Vérificateurs internes

Les vérificateurs internes doivent examiner et évaluer les contrôles de gestion utilisés dans l'élaboration de nouveaux systèmes d'application ou d'améliorations importantes. Ils chercheront des preuves d'une participation réelle de l'utilisateur dans l'analyse et l'acceptation du système; ils chercheront également des preuves d'une attention réelle portée à l'analyse détaillée du système et des procédures pour apporter un contrôle général et un contrôle dans l'application.

Le degré exact de participation des vérificateurs à l'élaboration des systèmes est déterminé par le risque encouru par l'organisme pour l'activité d'élaboration. Ce risque se compose des éléments de coûts d'élaboration, de coût opérationnel et de la dépendance de l'organisme vis-à-vis de l'information traitée. L'activité d'analyse et d'élaboration des systèmes représente aujourd'hui une part croissante du temps et des dépenses des organismes, et ces derniers sont plus dépendants que jamais vis-à-vis du fonctionnement continu de leurs systèmes informatiques. Le vérificateur doit, tout comme il établit l'importance relative de leurs constatations, donner les raisons pour lesquelles il a préféré certains critères à d'autres pendant l'étape de planification de la vérification. Pour ce faire, il détermine quel serait le risque pour le ministère si un contrôle de gestion particulier était mal exercé. Dans certains cas, cette approche permet de traiter de vastes projets d'élaboration des systèmes avec très peu de vérificateurs.

Il est possible que le vérificateur découvre des documents très complexes que l'on juge nécessaires pour expliquer la relation existant, dans le rôle de l'élaboration des systèmes, entre les gestionnaires de produits, les concepteurs des systèmes de communication, les administrateurs de bases de données, les détenteurs de données, les utilisateurs, les clients et de nombreux autres termes qui ont fait leur apparition pour traiter du monde plus complexe de l'informatique décrit au chapitre 1.

Sauf en ce qui concerne l'élaboration des exigences à l'égard des systèmes à l'intention du groupe de vérification, en tant qu'utilisateur du système, le vérificateur ne doit jamais être directement tenu responsable d'une activité de projet. Il se situe « en dehors » de l'équipe du projet même s'il peut lui offrir des conseils sur le contrôle, que ce soit par des lettres ou par des rapports. Il doit, dans toutes les étapes d'élaboration qui ont été décrites, vérifier que tous les points et les concepts touchant les rôles ou la présentation de rapports soient bien documentés.

Dans toutes leurs activités d'examen d'élaboration des systèmes, les vérificateurs doivent s'assurer que leur indépendance n'est pas compromise, en vue d'examens ultérieurs des systèmes en cours. On obtient normalement ce résultat en affectant des vérificateurs différents après que le système a été mis en place, lequel dépend aussi de la façon dont le vérificateur d'élaboration des systèmes observe les faiblesses de contrôle et recommande des améliorations à leur égard. Le vérificateur doit toujours s'opposer à participer à l'analyse même du système.

 




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).

 




Annexe A : Grille des entrevues

Légende

  • ABD = Administrateur de la base des données
  • C/A = Concepteur/analyste
  • GDM = Gestionnaire des données du ministère
  • Gest = Gestion
  • Prog = Programmeur
  • GP = Gestionnaire de projet
  • CD/PA = Comité directeur ou personne dotée du pouvoir d'approbation
  • Sécu = Agent de sécurité du ministère
  • Util = Users Utilisateurs
Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
1.A.1.1 X X X            
1.A.1.2 X X       X   X  
1.A.2.1 X X X     X      
1.A.2.2 X     X   X      
1.A.3.1   X              
1.A.3.2                  
1.A.3.3 X                
1.A.3.4                  
1.A.3.5 X X              
1.A.4.1 X                
1.A.4.2 X   X            
1.A.4.3 X     X          
1.A.5.1 X                
1.A.5.2 X                
1.A.5.3 X                
1.A.6.1     X            
1.A.6.2 X   X            

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
2.A.1.1       X   X      
2.A.1.2       X   X      
2.A.2.1 X   X            
2.A.2.2 X     X          
2.A.3.1 X         X      
2.A.3.2 X         X      
2.A.3.3 X         X      
2.A.4.1 X   X            
2.A.4.2 X   X     X      
2.A.5.1 X                
2.A.5.2 X         X      
2.A.6.1 X   X            
2.A.6.2 X   X     X      
2.A.7.1 X   X            
2.A.8.1 X   X     X      
2.A.8.2 X   X     X      
2.A.9.1 X   X     X      
2.A.9.2 X         X      
2.A.9.3 X         X      
2.A.9.4 X                
2.A.10.1 X   X            
2.A.10.2 X         X      
2.B.1.1 X     X   X X X  
2.B.1.2       X   X      
2.B.2.1 X   X            
2.B.3.1 X         X X    
2.C.1.1 X     X   X      
2.C.1.2 X     X   X      
2.C.2.1 X   X            

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
3.A.1.1 X     X   X      
3.A.1.2 X     X   X      
3.A.2.1 X   X            
3.A.3.1 X     X       X X
3.A.4.1 X                
3.A.5.1 X   X     X      
3.A.5.2 X   X     X      
3.A.6.1 X                
3.A.6.2 X         X      
3.A.6.3 X         X      
3.A.6.4 X         X      
3.A.6.5 X                
3.A.6.6 X         X      
3.A.7.1 X   X            
3.B.1.1 X     X   X      
3.B.1.2 X     X   X      
3.B.2.1 X   X            
3.C.1.1 X     X   X      
3.C.1.2 X     X   X      
3.C.2.1 X   X            

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
4.A.1.1 X     X          
4.A.1.2       X   X      
4.A.2.1 X   X            
4.A.3.1       X       X X
4.A.4.1 X     X   X      
4.A.4.2       X          
4.A.5.1 X   X     X      
4.A.6.1       X          
4.A.7.1 X                
4.A.8.1 X   X     X      
4.A.8.2 X   X            
4.A.9.1 X         X      
4.A.9.2 X         X      
4.A.9.3 X         X      
4.A.9.4 X         X      
4.A.9.5 X         X      
4.A.9.6 X         X      
4.A.10.1 X   X            
4.B.1.1 X     X          
4.B.1.2       X          
4.B.2.1 X   X            
4.C.1.1 X     X          
4.C.1.2       X          
4.C.2.1 X   X            

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
5.A.1.1 X     X   X      
5.A.2.1 X     X   X      
5.A.3.1 X     X   X      
5.A.3.2 X     X          
5.A.4.1 X   X            
5.A.5.1 X                
5.A.6.1 X   X     X      
5.A.6.2 X   X            
5.A.7.1 X         X      
5.A.7.2 X         X      
5.A.7.3 X         X      
5.A.7.4 X         X      
5.A.7.5 X         X      
5.A.7.6 X         X      
5.A.8.1 X   X            

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
6.A.1.1 X         X      
6.A.1.2 X     X   X      
6.A.2.1 X         X      
6.A.3.1 X     X   X      
6.A.3.2 X         X      
6.A.4.1 X         X      
6.A.4.2 X         X      
6.A.4.3 X         X      
6.A.4.4 X         X      
6.A.4.5 X         X      
6.A.4.6 X         X      
6.A.5.1 X     X   X      

 

Étape de vérification GP Gest CD/PA C/A Prog Util Sécu GDM ABD
7.A.1.1 X         X      
7.A.1.2 X         X      
7.A.1.3 X         X      
7.A.1.4 X         X      
7.A.1.5 X         X      






Annexe B : Programme de vérification de l'étape de lancement du projet

Étape : 1. Lancement du projet

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

Critère : 1.A.1. Déterminer si le rapport sur le lancement du projet (ou un document semblable) indique que le projet est nécessaire.

Étape de vérification : 1.A.1.1 Un document de lancement du projet a-t-il été publié par le gestionnaire du projet?

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.1.2 Vérifier si ce document contient au moins les points suivants :

  • un énoncé clair de la définition du projet préparé par le groupe client;
  • un lien clairement établi entre le plan de gestion de l'information (PGI) et le plan opérationnel pluriannuel (POP) du ministère;
  • des assurances que les données et le système ne sont pas déjà prévus dans des systèmes ou d'autres projets existants;
  • une évaluation du système en cours pour s'assurer que le système proposé est bien nécessaire;
  • un énoncé des contraintes internes et externes, p.ex. des changements organisationnels et des changements législatifs nécessaires, des incidences sur les autres systèmes;
  • les exigences particulières en matière de sécurité;
  • une analyse coûts/avantages préliminaire et l'analyse des risques pour les autres solutions viables;
  • une explication de la source du financement pour le projet, y compris un renvoi à toute exigence particulière, telle que les présentations au Conseil du Trésor.
Oui Non S/O Observations Renvois
         
Critère : 1.A.2. Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données jugent le projet nécessaire.

Étape de vérification : 1.A.2.1 Le document de lancement a été examiné à un niveau de gestion supérieur d'au moins un échelon aux personnes qui seront tenues directement responsables et la nécessité d'exécuter le projet a été reconnue.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.2.2 L'équipe de projet a pris des mesures pour repérer et consulter toutes les parties concernées.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.2.3 Le projet a été approuvé sur le plan financier.

Oui Non S/O Observations Renvois
         
Critère : 1.A.3 Déterminer si le rapport sur le lancement du projet indique l'organisation du projet.
Étape de vérification : 1.A.3.1 Déterminer, par examen du document de lancement du projet, les points suivants :
  • Les membres de l'équipe et les représentants ont été nommés incluant :
    • Le directeur (la directrice) du projet
    • Le gestionnaire du projet
    • Le directeur/gestionnaire utilisateur
    • Les représentants techniques
    • Représentant utilisateur fonctionnel
  • un comité directeur ou un pouvoir d'approbation ont été établis
  • le cas échéant, un fonctionnaire de la Direction des programmes du CT a été désigné et son rôle déterminé
Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.2 Examiner les antécédents et les qualifications des membres du projet pour les affecter à des tâches particulières.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.3 La direction du ministère client a-t-elle affecté au projet des employés de son ministère?

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.4 Les employés du ministère client et l'équipe de projet comprennent-ils de la même façon la portée et les objectifs du projet?

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.5 Déterminer si le gestionnaire de projet, ou l'un des membres de l'équipe, a la responsabilité de s'assurer d'une compilation complète et exacte des coûts du projet.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.6 Déterminer si le comité directeur ou les détenteurs du pouvoir d'approbation représentent bien la gestion, que leur niveau est supérieur d'au moins un échelon à celui du gestionnaire de projet, et qu'ils représentent également toutes les parties intéressées.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.3.7 Déterminer si l'on a établi et vérifié le niveau, exigé et réel, d'autorisation de sécurité et de fiabilité s'appliquant aux membres de l'équipe.

Oui Non S/O Observations Renvois
         
Critère : 1.A.4 Déterminer si le rapport sur le lancement du projet indique les étapes de réalisation du projet.

Étape de vérification : 1.A.4.2 Des variantes du processus ministériel approuvé ont-elles été relevées et les motifs de l'écart ont-ils été énoncés?

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.4.3 Déterminer si la création de prototypes (voir le début du chapitre 2) a été considérée comme une technique d'élaboration possible, en portant attention aux points suivants :

  • la prévention de l'abus de prototypes (voir au chapitre 2, page 16, la description sommaire d'un prototype);
  • le recours au prototype aux étapes appropriées (c.-à-d. de l'étape de faisabilité à celle de la conception générale);
  • la participation réelle des utilisateurs à l'élaboration des prototypes (déterminer si le prototype tient bien compte des besoins des utilisateurs);
Oui Non S/O Observations Renvois
         
Critère : 1.A.5 Déterminer si le rapport sur le lancement du projet renferme un plan de travail qui indique, notamment, les délais fixés.

Étape de vérification : 1.A.5.1 Déterminer en se référant au document de lancement du projet si un plan de travail comportant un échéancier et des exigences en matière de ressources a été préparé.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.5.2 Vérifier si le total des exigences en matière de ressources indiqué dans le plan de travail correspond aux résultats de l'analyse coûts/avantages préliminaire.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.5.3 Vérifier si l'échéancier qui figure dans le plan de travail tient compte des exigences en matière de ressources indiquées et de toutes les contraintes.

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.5.4 Vérifier si le plan de travail prévoit l'élaboration d'un plan en matière de ressources humaines pour tous les employés qui seront touchés par le nouveau système.

Oui Non S/O Observations Renvois
         
Critère : 1.A.6 Déterminer si 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é.

Étape de vérification : 1.A.6.1 Le document de lancement a-t-il été examiné par des niveaux de gestion supérieurs d'au moins un échelon aux personnes qui siégeront au comité directeur ou qui détiennent le pouvoir d'approbation? Ont-ils accepté l'organisation, le processus d'élaboration et le plan de travail?

Oui Non S/O Observations Renvois
         

Étape de vérification : 1.A.6.2 Existe-t-il un plan pour que le gestionnaire de projet présente des rapports périodiques à la gestion et les rapports contiendront-t-ils les coûts et les réalisations du projet, en comparaison des plans.

Oui Non S/O Observations Renvois
         





Annexe C : Programme de vérification de l'étape de l'étude de faisabilité

Étape : 2. Étude de faisabilité

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ère : 2.A.1 Déterminer si le rapport sur les besoins des utilisateurs (ou un document de ce genre) examine les besoins des utilisateurs.

Étape de vérification : 2.A.1.1 Un document des exigences de l'utilisateur a-t-il été préparé et communiqué? Tient-il compte des besoins suivants de l'organisme pour l'accomplissement de sa mission :

  • description de la fonction actuelle;
  • lacunes de la fonction actuelle;
  • ressources affectées à la fonction actuelle;
  • volume de travail produit avec la fonction actuelle, y compris le rendement en période de pointe et la croissance prévue;
  • exigences en matière de contrôle interne et de sécurité;
  • justification des améliorations et des changements;
  • portée et objectifs du système proposé;
  • solutions autres que la satisfaction du besoin;
  • liens avec d'autres systèmes;
  • liens avec les plans à long terme et d'autres documents pour la gestion des ressources informatiques.

Note : L'ouvrage de Gane et Sarson, appendice I, point 22, contient d'autres points se rapportant à l'analyse des besoins des utilisateurs.

Oui Non S/O Observations Renvois
         
Critère : 2.A.2 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que la définition des besoins est précise et complète.

Étape de vérification : 2.A.2.1 Le document des exigences de l'utilisateur a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation?

  • Ces personnes conviennent-elles de la nécessité d'exécuter le projet. Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.2.2 L'équipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernées.

Oui Non S/O Observations Renvois
         
Critère : 2.A.3 Déterminer si l'étude de faisabilité (ou un document de ce genre) renferme une analyse des solutions de rechange.

Étape de vérification : 2.A.3.1 Une étude de faisabilité technologique a-t-elle été préparée et documentée?

  • Existe-t-il des normes organisationnelles relatives au contenu des études de faisabilité technologique et à la façon de les exécuter?
  • La technologie proposée est-elle réalisable compte tenu du degré de perfectionnement sur le plan technique qui existe ou qui est disponible dans l'organisme.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.3.2 Vérifier si cette étude porte sur les points suivants :

  • besoins en matériel et disponibilité du matériel;
  • besoins en logiciels et disponibilité des logiciels;
  • besoins en matériel et en logiciels de communications et disponibilité du matériel et des logiciels;
  • contraintes de temps valables relatives aux besoins en information du ministère client et façon de les satisfaire;
  • faisabilité sur le plan opérationnel (c.-à-d., le nouveau projet s'intègre-t-il bien au matériel, aux logiciels et aux systèmes de communications en place?);
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.3.3 Vérifier si les ministères clients et les concepteurs s'entendent sur les aspects technologiques de la configuration du système.

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.3.4 Déterminer si l'organisme est en mesure de gérer les technologies connexes et de décider si elles doivent être achetées ou conçues, exploitées sur place ou à l'extérieur et si leur maintenance doit se faire sur place ou à l'extérieur.

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.3.5 confirmer auprès de sources indépendantes la fiabilité et la performance du matériel et des logiciels recommandés.

Oui Non S/O Observations Renvois
         
Critère : 2.A.4 Déterminer si 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, et s'ils approuvent les recommandations formulées.

Étape de vérification : 2.A.4.1 L'étude de faisabilité a-t-elle été examinée par le comité directeur ou les détenteurs du pouvoir d'approbation?

  • Ces personnes conviennent-elles de la nécessité d'exécuter le projet? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.4.2 L'équipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernées?

Oui Non S/O Observations Renvois
         
Critère : 2.A.5 Déterminer si le rapport sur l'analyse coûts/avantages (ou un document semblable) renferme une estimation des ressources humaines et financières requises.

Étape de vérification : 2.A.5.1 Un document des coûts et des avantages a-t-il été préparé et communiqué? Tous les coûts sont-ils définis comme coûts de fonctionnement ou coûts d'immobilisations?

Note : On doit également se servir, à ce point de la vérification, de l'information provenant des comités consultatifs sur la gestion de l'information (CCGI) comme document de référence.

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.5.2 Vérifier si l'analyse des coûts et des avantages du projet a été faite dans le but d'évaluer la faisabilité sur le plan économique de chaque solution de rechange.

  • les hypothèses et les contraintes relatives au caractère raisonnable de l'analyse coûts/avantages; 
  • les coûts du système et de l'utilisateur couvrent toutes les étapes du cycle de vie;
  • les coûts estimatifs de la solution de rechange comprennent toutes les améliorations du matériel et du logiciel qui seront nécessaires au soutien de cette solution de rechange;
  • les coûts estimatifs de la solution de rechange comprennent les coûts de la sécurité et des contrôles internes, de la préparation et de l'entrée des données, de la conversion des fichiers, des essais, des activités parallèles, de l'acceptation et les coûts connexes;
  • la base ayant servi au calcul et à l'estimation est raisonnable;
  • les utilisateurs, les concepteurs et les personnes chargées de mettre le système en place sont d'accord sur les coûts du système, les avantages et les ententes contractuelles.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.5.3 Veiller à ce que l'analyse des coûts et des avantages du projet tienne compte des incidences sur les ressources humaines. Vérifier si les coûts estimatifs de chaque solution de rechange comprennent :

  • de la formation et
  • le redéploiement de l'effectif.
Oui Non S/O Observations Renvois
         
Critère : 2.A.6 Déterminer si 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 s'ils approuvent la solution de rechange recommandée.

Étape de vérification : 2.A.6.1 Le document des coûts et des avantages a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ces personnes acceptent-elles l'autre solution de traitement recommandée, et conviennent-elles de la nécessité de continuer le projet? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.6.2 L'équipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernées?

Oui Non S/O Observations Renvois
         
Critère : 2.A.7 Déterminer si 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 du personnel (aptitudes administratives et techniques requises, niveau de compétence requis, nombre d'employés requis, niveau d'autorisation nécessaire).

Étape de vérification : 2.A.7.1 Le gestionnaire du projet a-t-il préparé un résumé des compétences du personnel?

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.7.2 Le résumé des compétences du personnel porte-t-il sur les points suivants :

  • compétences nécessaires (administratives et techniques)
  • niveaux de compétences nécessaires
  • nombre d'employés nécessaires
  • niveau de pouvoir nécessaire.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.7.3 La documentation sur le projet montre-t-elle que les compétences des employés affectés au projet (en qualité de membres de l'équipe, du comité directeur ou de détenteurs du pouvoir d'approbation) sont conformes à celles qui figurent dans le résumé des compétences du personnel?

Oui Non S/O Observations Renvois
         
Critère : 2.A.8 Déterminer si 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.

Étape de vérification : 2.A.8.1 Un document sur le calendrier des réunions du comité directeur a-t- il été préparé et communiqué à toutes les parties intéressées, y compris la gestion de l'informatique et la gestion des utilisateurs?

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.8.2 Examiner les procès-verbaux des réunions du comité et noter les points suivants :

  • la présence de représentants de la gestion de l'informatique et de la gestion des utilisateurs à chaque réunion;
  • la tenue régulière de réunions.
Oui Non S/O Observations Renvois
         
Critère : 2.A.9 Déterminer si le rapport sur l'étude de faisabilité (ou un document de ce genre) compare la réalisation du projet au plan de travail contenu dans le rapport sur le lancement du projet.

Étape de vérification : 2.A.9.1 Un rapport d'étape de l'étape de faisabilité a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.9.2 Vérifier si ce document contient au moins les points suivants :

  • utilisation réelle des ressources, en comparaison avec le plan; raisons des écarts enregistrés;
  • jalons réels atteints en comparaison avec le plan; raisons des écarts enregistrés;
  • plan détaillé de l'étape de conception générale, avec renvois aux activités suivantes :
    • analyse et spécification des exigences détaillées de l'utilisateur,
    • établissement des processus de contrôle des changements,
    • mise à jour de l'analyse coûts/avantages,
    • obtention de l'approbation de la gestion;
  • mise à jour des budgets et raisons de tout changement;
  • mise à jour du calendrier et raisons de tout changement;
  • recommandation de continuer ou d'arrêter le projet.
Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.9.3 Vérifier l'utilisation réelle des ressources en se servant des documents de base.

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.9.4 Vérifier si le budget et le calendrier mis à jour correspondent à l'étude de faisabilité et à l'analyse coûts/avantages.

Oui Non S/O Observations Renvois
         
Critère : 2.A.10 Déterminer si 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 s'ils l'approuvent.

Étape de vérification : 2.A.10.1 Le rapport de l'étape de faisabilité a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? L'ont-ils accepté?

Oui Non S/O Observations Renvois
         

Étape de vérification : 2.A.10.2 L'équipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernées?

Note :  Il est possible que le document d'analyse coûts/avantages et le rapport de l'étape de faisabilité soient combinés. Dans tous les cas, l'acceptation par la gestion de la recommandation contenue dans l'analyse coûts/avantages équivaudra à l'acceptation de la mise à jour du budget. Il en va autrement pour la mise à jour du calendrier.

Oui Non S/O Observations Renvois
         

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ère : 2.B.1 Déterminer si la fiche de contrôle (ou un document de ce genre) indique les mesures de contrôle prévues.

Étape de vérification : 2.B.1.1 L'étude de faisabilité fait-elle état de la nécessité de préparer un document de spécification des contrôles du traitement du système ou un document du genre?

Oui Non S/O Observations Renvois
         
Critère : 2.B.2 Déterminer si le représentant des utilisateurs a pris bonne note des mesures de sécurité, de protection des renseignements personnels et d'accès à l'information.

Étape de vérification : 2.B.2.1 Déterminer si l'énoncé du niveau de sécurité, de protection des renseignements personnels et d'accessibilité est conforme aux politiques du CT (se reporter à l'appendice J pour y trouver une liste des documents pertinents) ou aux lois du gouvernement et si cet énoncé figure dans la documentation à examiner par le comité directeur ou les détenteurs du pouvoir d'approbation.

Oui Non S/O Observations Renvois
         

Objectif : 2.C Déterminer si le système est exploité de façon efficace, efficiente et économique.

Critère : 2.C.1 Déterminer si 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.

Étape de vérification : 2.C.1.1 L'étude de faisabilité reconnaît-elle la nécessité d'un document des spécifications des contrôles de gestion du système, ou d'un document du genre?

Oui Non S/O Observations Renvois
         





Annexe D : Programme de vérification de l'étape de conception générale

Étape : 3. Conception générale

Objectif : 3.A S'assurer que la conception générale du système s'inspire des résultats obtenus par l'étude de faisabilité, qu'elle permette de produire une description fonctionnelle des processus manuels et informatiques, et qu'elle permette une analyse globale du système pouvant être utilisée pour obtenir un engagement à une élaboration ultérieure.

Critère : 3.A.1 Les spécifications des systèmes doivent figurer dans un rapport sur les spécifications des systèmes, ou dans un document de ce genre.

Étape de vérification : 3.A.1.1 Un document des spécifications des systèmes a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.1.2 Vérifier si ce document contient au moins les points suivants :

  • Objectifs et portée des systèmes.
  • Considérations générales sur les concepts et la conception des systèmes.
  • Tableau indiquant la structure des fonctions en termes des processus.
  • Diagramme de cheminement des données logiques, indiquant le cheminement dans les processus et les stocks de données au niveau des éléments de données.
  • Description des processus comportant les définitions complètes et détaillées des processus s'appliquant à tous les cas de gestion concernés. Ces descriptions comprendront les algorithmes et les contrôles de la validité.
  • Interface des systèmes: Définitions au niveau des éléments de données.
  • Entrées et sorties de systèmes. Les définitions au niveau des éléments de données pour le mode seront utilisées pour les entrées et les sorties spécifiées.
  • Stocks de données. Définitions des stocks de données logiques au niveau des éléments de données.
  • Volumes, synchronisations, maxima et minima, qualité spécifiés pour les entrées, les sorties et les stocks de données.
  • Niveaux de service. Description complète des exigences en matière de performance. Utilisation dans les étapes subséquentes pour confirmer la faisabilité technique et les exigences en ressources du système.
  • Exigences en matière de vérification, de contrôle et de sécurité.
  • Exigences en matière de mise en oeuvre, y compris la conversion.

(voir l'ouvrage de Gane et Sarson, point 22 de l'appendice I, pour y trouver une description de quelques-uns de ces éléments.)

Oui Non S/O Observations Renvois
         
Critère : 3.A.2 Le caractère exact et complet des spécifications des systèmes doit être reconnu à l'échelon approprié des utilisateurs et de la gestion de l'informatique.

Étape de vérification : 3.A.2.1 Le document des spécifications des systèmes a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci reconnaissent-ils la nécessité de continuer le projet? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         
Critère : 3.A.3 Le dictionnaire ou le répertoire des données doit être mis à jour pour refléter le contenu des spécifications des systèmes.

Étape de vérification : 3.A.3.1 Le dictionnaire ou le répertoire de données a-t-il été mis à jour et contient-il les spécifications des systèmes?

Oui Non S/O Observations Renvois
         
Critère : 3.A.4 Toutes les compétences nécessaires doivent être mises à la disposition du projet.

Étape de vérification : 3.A.4.1 Les compétences du personnel employé au projet (en qualité de membres de l'équipe, de membres du comité directeur ou de détenteurs du pouvoir d'approbation) continuent-elles à répondre aux exigences spécifiées dans le résumé des compétences du personnel?

Oui Non S/O Observations Renvois
         
Critère : 3.A.5 Les dates des réunions du comité et les points à discuter à l'occasion de celles-ci doivent continuer à figurer dans un calendrier des réunions du comité directeur ou dans un document du genre.

Étape de vérification : 3.A.5.1 Un calendrier des réunions du comité directeur a-t-il été préparé et communiqué à toutes les parties intéressées, y compris la gestion de l'informatique et la gestion cliente?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.5.2 Assister aux réunions du comité ou en examiner les procès-verbaux, en notant les points suivants :

  • la présence des représentants de la gestion de l'informatique et de la gestion des utilisateurs à chaque réunion;
  • la tenue régulière de réunions.
Oui Non S/O Observations Renvois
         
Critère : 3.A.6 L'état du projet par rapport au budget et au calendrier contenus dans le document connexe de l'étape de faisabilité doit figurer dans le rapport sur les progrès réalisés à l'étape d'analyse générale ou dans un document de ce genre.

Étape de vérification : 3.A.6.1 Un document des progrès réalisés à l'étape de conception générale a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.6.2 Vérifier si ce document contient au moins les points suivants :

  • utilisation réelle des ressources, en comparaison avec le plan; raisons des écarts enregistrés;
  • jalons réels atteints, en comparaison avec le plan; raisons des écarts enregistrés;
  • plan détaillé de l'étape de conception détaillée, avec renvois aux activités suivantes :
    • mise à jour du dictionnaire ou du répertoire de données,
    • exécution de la conception finale de toutes les entrées et de toutes les sorties,
    • élaboration du plan détaillé de tests,
    • vérifier si les normes de sécurité ont été respectées
    • développer un plan de tests détaillés
    • mise à jour des plans et budgets des projets,
    • mise à jour des analyses coûts/avantages,
    • obtention de l'approbation de la gestion;
  • plan préliminaire pour l'étape de mise en oeuvre, y compris les points suivants :
    • relevé des procédures manuelles à élaborer,
    • manuels touchés,
    • besoins en matière d'installations,
    • besoins en matière de communications,
    • formation,
  • budget mis à jour et raisons de tout changement,
  • calendrier mis à jour et raisons de tout changement,
  • analyse des coûts/ avantages mise à jour,
  • recommandation de continuer ou d'arrêter le projet.
Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.6.3 Vérifier l'utilisation réelle des ressources avec renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.6.4 Le budget et le calendrier mis à jour correspondent-ils à l'analyse coûts/avantages mise à jour?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.6.5 Vérifier l'analyse coûts/avantages mise à jour par rapport à l'analyse coûts/avantages provenant de l'étape précédente et aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.6.6 Déterminer si l'analyse coûts/avantages mise à jour tient compte des exigences se rapportant aus incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critère : 3.A.7 Le caractère exact et complet du document d'étape de l'étape d'analyse et l'accord qu'il a entraîné doivent être reconnus à l'échelon approprié des utilisateurs et de la gestion de l'informatique.

Étape de vérification : 3.A.7.1 Le document d'étape de l'étape de conception générale a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation et ceux-ci l'ont accepté?

Oui Non S/O Observations Renvois
         
Critère : 3.A.8 Une analyse des incidences sur les ressources humaines est prévue.

Étape de vérification : 3.A.8.1 Le plan détaillé pour l'étape de conception détaillée prévoit-il une analyse des incidences sur les ressources humaines? L'analyse prévue vise-t-elle tous les employés qui seront touchés (c'est-à-dire les employés qui recevront une formation pour le nouveau système et ceux qui devront être redéployés)?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.8.2 Le plan détaillé pour l'étape de conception détaillée prévoit-il la diffusion de renseignements sur le nouveau système (c'est-à-dire la communication avec tous ceux qui seront touchés, les répercussions du système sur le ministère et sur les employés)?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.A.8.3 Le plan préliminaire de l'étape de mise en oeuvre comprend-il la prise de mesures relatives aux points qui figurent dans l'analyse des incidences sur les ressources humaines?

Objectif : 3.B S'assurer que les données traitées et stockées par le système soient complètes, exactes et autorisées.

Critère : 3.B.1 Les techniques de contrôle du traitement doivent figurer dans un rapport sur les spécifications des contrôles du traitement du système ou dans un document de ce genre.

Étape de vérification : 3.B.1.1 Un document des spécifications des contrôles du traitement a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.B.1.2 Vérifier s'il traite au moins des points suivants (voir l'appendice pour d'autres références à des contrôles de données) :

  1. Caractère complet
    1. Il faut une méthode permettant de s'assurer que toutes les données soient enregistrées et relevées au début.
    2. On doit établir le contrôle près de la source de l'opération.
    3. On doit rapprocher les sorties et les entrées.
    4. Il faut une méthode permettant de s'assurer que les corrections soient entrées dans le système pour toutes les erreurs identifiées.
    5. On doit veiller à synchroniser les soumissions de données et la distribution des sorties avec le traitement.
    6. On doit mettre en place des procédures d'examen indépendant de la forme et du caractère complet des rapports de sorties.
  2. Exactitude
    1. Il faut des procédures permettant de prévenir les erreurs dans la préparation des entrées ou des données sources, ainsi que pour déceler et corriger toutes les erreurs importantes qui se sont produites.
    2. Il faut des procédures pour prévenir les erreurs dans la conversion des données en une forme se prêtant au traitement automatisé, ainsi que pour déceler et corriger toutes les erreurs importantes qui se sont produites.
    3. Il faut des procédures permettant d'assurer la transmission exacte des données au centre informatique.
    4. Les procédures doivent être documentées pour assurer le bon fonctionnement de l'équipement informatique, ainsi que la détection des cas de mauvais fonctionnement et des erreurs de données qui en résultent.
    5. Des procédures doivent assurer l'utilisation de fichiers valides seulement.
    6. Des contrôles doivent assurer le maintien de l'exactitude des données pendant tout le traitement.
    7. Des procédures doivent assurer la bonne exécution des calculs de programmes.
    8. Il faut un système de contrôle sur les opérations manuelles du système informatique.
    9. Des procédures doivent assurer que toutes les erreurs importantes décelées à diverses étapes du système ont été corrigées et que les corrections ont été réentrées et bien indiquées dans la sortie.
    10. Des procédures doivent garantir que tous les rapports de sortie requis sont livrés aux ministères clients appropriés.
  3. Autorisation
    1. Assurer le traitement des données autorisées seulement.
    2. On devra avoir déterminé les classifications de niveau de sécurité, de protection des renseignements personnels et d'accessibilité (voir 2.B1.2.1), en ce qui concerne les données se rapportant au système, et on devra avoir conçu les mesures appropriées pour assurer le stockage, la transmission, l'accès, la protection et la destruction qui conviennent à ces données.
    3. Il faut une méthode permettant de relever et de retrouver les dossiers de fichiers, ainsi que les documents d'entrées ou de sorties reliés au traitement d'une opération donnée, ou à l'accumulation d'un total donné.
  4. Appui/Relance
    1. Les procédures de sauvegarde ou de relance des systèmes doivent être documentées et on doit préparer les plans de formation s'y rapportant.
    2. Les procédures de préparation des données, de transcription et de contrôle des données, ainsi que de distribution des sorties doivent être documentées, et des plans de formation connexes doivent être préparés.
  5. Piste de vérification
    1. Il faut une méthode permettant de reconnaître et de retrouver les dossiers de fichiers, ainsi que les documents d'entrées ou de sorties reliés au traitement d'une opération donnée, ou à l'accumulation d'un total donné.

Note : Différents concepts en matière de contrôle s'appliquent à différents genres de système (par exemple, par lots plutôt qu'en direct). La bibliographie à l'appendice I renferme des ouvrages sur les contrôles pour divers genres de systèmes.

Oui Non S/O Observations Renvois
         
Critère : 3.B.2 Le caractère exact et complet des spécifications des techniques de contrôle du traitement doit être reconnu à l'échelon approprié des utilisateurs et de la gestion de l'informatique.

Étape de vérification : 3.B.2.1 Le document des spécifications des contrôles du traitement a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté. Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         
Critère : 3.C.1 Les techniques de contrôle de la gestion des systèmes doivent être indiquées dans un document sur les spécifications des contrôles de la gestion des systèmes ou dans un document du genre.

Étape de vérification : 3.C.1.1 Un document des spécifications des contrôles de la gestion des systèmes a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 3.C.1.2 Vérifier si ce document traite au moins des points suivants :

  1. Efficience
    1. Une norme ou une série de normes permettant de mesurer l'efficience du système doivent exister.
    2. Il faut un moyen de comparer le rendement aux normes et de faire rapport sur les écarts.
    3. Il faut des procédures de suivi à l'intention des gestionnaires à l'égard des déviations des normes et de la consignation des mesures prises.
  2. Efficacité
    1. Il faut établir des normes d'efficacité relatives aux objectifs du système.
    2. Il faut établir une méthode permettant de déceler les cas où les systèmes ne peuvent plus atteindre leurs objectifs initiaux et de faire rapport sur ces cas.
  3. Économie
    1. La gestion doit mettre en oeuvre des procédures officielles pour l'examen périodique de l'économie de ses projets et des applications du système qui en découlent.
Oui Non S/O Observations Renvois
         
Critère : 3.C.2 Le caractère exact et complet des spécifications des techniques de contrôle de la gestion des systèmes doit être reconnu à l'échelon approprié des utilisateurs et de la gestion de l'informatique.

Étape de vérification : 3.C.2.1 Le document des spécifications des contrôles de la gestion des systèmes a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         





Annexe E : Programme de vérification de l'étape de conception détaillée

Étape : 4. Conception détaillée

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ère : 4.A.1 Déterminer si le rapport sur la conception détaillée (ou un document de ce genre) fait état des caractéristiques de la programmation.

Étape de vérification : 4.A.1.1 Un document sur la conception détaillée des systèmes a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.1.2 Vérifier si ce document couvre au moins les points suivants :

  • Acheminement des systèmes et description par fonction.
  • Dictionnaire des éléments de données.
  • Fichiers de systèmes.
  • Entrées de systèmes, y compris la conception des formules et des écrans.
  • Sorties de systèmes, y compris la conception des formules, des rapports et des écrans.
  • Spécifications de l'interface de systèmes.
  • Spécifications des logiciels de systèmes.
  • Spécifications du matériel.
  • Spécifications des communications.
  • Spécifications de l'installation pour la gestion des systèmes.
  • Spécifications de la vérification, du contrôle et de la sécurité.
  • Spécifications du module de traitement en commun.
  • Spécifications de la conversion.
Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.1.3 Vérifier si les spécifications des systèmes pour chaque application du système sont claires, complètes et uniformes.

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.1.4 Évaluer le caractère raisonnable de la logique du programme intégrée dans les applications par l'examen des graphiques d'acheminement, des tables de décisions ou des rapports narratifs.

Oui Non S/O Observations Renvois
         
Critère : 4.A.2 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que les caractéristiques sont précises et complètes.

Étape de vérification : 4.A.2.1 Le document de conception détaillée des systèmes a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         
Critère : 4.A.3 Détermineer si 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.

Étape de vérification : 4.A.3.1 Le dictionnaire ou le répertoire de données a-t-il été mis à jour et contient-il les spécifications détaillées des systèmes?

Oui Non S/O Observations Renvois
         
Critère : 4.A.4 Le plan de mise à l'essai (ou un document de ce genre) indique les mises à l'essai prévues.

Étape de vérification : 4.A.4.1 Un plan des tests a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.4.2 Vérifier si ce document contient au moins les points suivants, pour les tests des programmes et des systèmes, ainsi que pour le volume et l'aspect opérationnel :

  • Vue d'ensemble des logiciels à tester, y compris ceux du fournisseur et ceux de conversion, ainsi que l'environnement de travail où ils s'inscrivent. - Calendrier des tests.
  • Emplacements avec les exigences en matière de déplacements spéciaux et d'hébergement.
  • Matériaux et fournitures, y compris équipements, logiciels, installations de stockage (magnétique et physique), personnel, documentation, entrées à tester, échantillons de sorties et formules spéciales.
  • Exigences en matière de formation.
  • Liste des exigences de l'utilisateur à tester.
  • Liste des exigences opérationnelles à tester.
  • Vue d'ensemble de la progression des tests.
  • Description des tests à mener pour chaque exigence, y compris le type d'entrées à utiliser, la méthode d'enregistrement des résultats, les contraintes telles que celles d'équipement ou de disponibilité du personnel, les critères d'évaluation, ainsi que toute manipulation des données nécessaire à la présentation de rapports.
Oui Non S/O Observations Renvois
         
Critère : 4.A.4 Le plan de mise à l'essai (ou un document de ce genre) indique les mises à l'essai prévues.

Étape de vérification : 4.A.4.3 Comparer les renseignements contenus dans le plan des tests à l'une des normes ou l'un des guides suivants :

  • la norme relative aux plans de test des systèmes et la norme relative aux plans de test des unités telles qu'énoncées dans <<The Institute for Electrical System Test Plan Standard and Unit Test Plan Standard>>.
  • Le guide d'Auerbach A Standard for Testing Application Software.
Oui Non S/O Observations Renvois
         
Critère : 4.A.5 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le plan de mise à l'essai est précis et complet.

Étape de vérification : 4.A.5.1 Le document de plan des tests a-t- il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté? Noter toute acceptation conditionnelle pour effectuer un suivi dans les étapes à venir.

Oui Non S/O Observations Renvois
         
Critère : 4.A.6 Le plan de mise à l'essai tient compte des besoins des utilisateurs.

Étape de vérification : 4.A.6.1 Tous les éléments du document des exigences des utilisateurs sont-ils assujettis à des tests? Des tests adéquats peuvent inclure : des revues de projets, simulations et prototypes. Là où des points ne sont pas testés, vérifier si une explication a été donnée au comité directeur ou aux détenteurs du pouvoir d'approbation et acceptée par ceux-ci.

Oui Non S/O Observations Renvois
         
Critère : 4.A.7 Toutes les ressources humaines requises ont été affectées à la réalisation du projet.

Étape de vérification : 4.A.7.1 Les compétences du personnel employé au projet (en qualité de membres de l'équipe, de membres du comité directeur ou de détenteurs du pouvoir d'approbation) répondent-elles encore aux exigences spécifiées dans le résumé des compétences du personnel?

Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 4.A.8.1 Un calendrier des réunions du comité directeur a-t-il été préparé et communiqué à toutes les parties intéressées, y compris la gestion de l'informatique et la gestion des clients?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.8.2 Assister aux réunions du comité ou en examiner les procès-verbaux, en notant les points suivants :

  • la présence des représentants de la gestion de traitement électronique des données (TED) et de la gestion des clients à chaque réunion;
  • la tenue régulière de réunions.
Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 4.A.9.1 Un document d'étape de l'étape de conception détaillée a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.9.2 Vérifier si ce document contient au moins les points suivants : 

  • utilisation réelle des ressources, en comparaison avec celles prévues, et raisons des écarts enregistrés;
  • jalons réels atteints, en comparaison avec ceux prévus; raisons des écarts enregistrés;
  • plan détaillé de l'étape de mise en oeuvre, notamment avec renvoi aux activités suivantes :
    • conception des structures, de la logique et du cheminement de chaque composant du système,
    • conception de toutes les bases de données et de tous les fichiers,
    • évaluation de la performance des systèmes et des exigences en matières de ressources; confirmation que les niveaux de service seront atteints,
    • conception des outils de conversion,
    • programmes de codage et de tests,
    • achat et tests des logiciels du fournisseur,
  • intégration des programmes dans les sous-systèmes et systèmes,
    • rédaction de manuels et procédures des utilisateurs,
    • rédaction de manuels de conversion et de formation, ainsi que de manuels opérationnels,
    • conduite de tests de volume et de tests opérationnels,
    • documentation des programmes et des systèmes,
    • mise à jour des plans et des budgets du projet,
    • mise à jour des analyses coûts/avantages,
    • obtention de l'approbation de la gestion;
  • plan préliminaire pour l'étape de mise en place, y compris les points suivants :
    • conversion des fichiers
    • formation
    • manuels d'instruction
    • redéploiement de l'effectif
    • date de mise en service
  • budget mis à jour et raisons de tout changement
  • calendrier mis à jour et raisons de tout changement
  • analyse des coûts et avantages mise à jour
  • recommandation de continuer ou d'arrêter le projet.
Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.9.3 Vérifier l'utilisation réelle des ressources avec renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.9.4 Vérifier si le budget et le calendrier mis à jour correspondent à l'analyse coûts/avantages mise à jour.

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.9.5 Comparer l'analyse coûts/avantages mise à jour à l'analyse coûts/avantages provenant de l'étape précédente et des documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.9.6 L'analyse coûts/avantages mise à jour tient-elle compte des exigences se rapportant à l'incidence sur les ressources humaines?

Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 4.A.10.1 Le document d'étape de l'étape de conception détaillée a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté?

Oui Non S/O Observations Renvois
         
Critère : 4.A.11 Déterminer si une analyse de l'incidence sur les ressources humaines a été effectuée.

Étape de vérification : 4.A.11.1 Une analyse des incidences sur les ressources humaines a-t- elle été effectuée?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.A.11.2 Le comité directeur ou les détenteurs du pouvoir d'approbation ont-ils examiné les conclusions de l'analyse?

Oui Non S/O Observations Renvois
         

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ère : 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.

Étape de vérification : 4.B.1.1 Un plan des tests a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.B.1.2 Vérifier s'il traite des exigences en matière de contrôle indiquées dans le document des spécifications du contrôle du traitement (voir l'objectif 3.B.1).

Oui Non S/O Observations Renvois
         

Objectif : 4.C. Le système est exploité de façon efficace et efficiente.

Critère : 4.C.1 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.

Étape de vérification : 4.C.1.1 Un document de plan des tests a-t- il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 4.C.1.2 Vérifier s'il traite des exigences en matière de contrôle indiquées dans le document des spécifications des contrôles de la gestion des systèmes (voir l'objectif 3.C.1).

Oui Non S/O Observations Renvois
         





Annexe F : Programme de vérification de l'étape de la mise en oeuvre

Étape : 5. Mise en oeuvre

Objectif : 5.A Tous les formulaires, manuels, programmes et documents de formation appropriés ont été préparés à partir des caractéristiques de l'analyse détaillée.

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

Étape de vérification : 5.A.1.1 Déterminer si les éléments suivants ont été préparés :

  • instruments de conversion
  • manuels de l'utilisateur
  • manuels de conversion
  • manuels de formation
  • manuels d'opérations
  • documentation des programmes et systèmes.
Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.1.2 Vérifier si le manuel dutilisation :

  • décrit les fonctions avec suffisamment de détail
  • renferme de la terminologie non informatique
  • indique quand et comment il doit être utilisé
  • sert de document de référence - explique comment préparer les données d'entrée et les paramètres
  • explique comment interpréter les sorties
  • décrit l'application en détail
  • décrit comment corriger les erreurs
  • décrit comment reconstituer les opérations.
Oui Non S/O Observations Renvois
         
Critère : 5.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que les manuels et documents requis renferment des données complètes et précises.

Étape de vérification : 5.A.2.1 Les manuels et sorties nécessaires ont-ils été examinés par tous les membres de l'équipe de projet et ceux-ci les ont-ils acceptés? Noter toute acceptation conditionnelle pour effectuer un suivi dans l'étape suivante.

Oui Non S/O Observations Renvois
         
Critère : 5.A.3 Le rapport sur la mise à l'essai (ou un document de ce genre) fait état des résultats obtenus.

Étape de vérification : 5.A.3.1 Un document de rapport sur les tests a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.3.2 Vérifier si ce document couvre au moins les points suivants en ce qui concerne les tests des programmes et des systèmes, ainsi que les tests du volume et des opérations :

  • résultats des tests
  • raisons pour les tests non réalisés
  • action du suivi adoptée le cas échéant d'après les résultats des tests.
Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 5.A.4.1 Le document de rapport sur les tests a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté? Noter toute acceptation conditionnelle pour effectuer un suivi dans l'étape suivante.

Oui Non S/O Observations Renvois
         
Critère : 5.A.5 Toutes les ressources humaines nécessaires ont été affectées à la réalisation du projet.

Étape de vérification : 5.A.5.1 Les compétences du personnel employé au projet (en qualité de membres de l'équipe, de membres du comité directeur ou de détenteurs du pouvoir d'approbation) répondent-elles encore aux exigences spécifiées dans le résumé des compétences du personnel?

Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 5.A.6.1 Un calendrier des réunions du comité directeur a-t-il été préparé et communiqué à toutes les parties intéressées, y compris la gestion de l'informatique et la gestion des clients?

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.6.2 Assister aux réunions du comité ou en examiner les procès-verbaux, en notant les points suivants :

  • la présence de représentants de la gestion de l'information de la gestion des clients à chaque réunion;
  • la tenue régulière de réunions.
Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 5.A.7.1 Un document d'étape de l'étape de mise en oeuvre a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.7.2 Vérifier si ce document contient au moins les points suivants :

  • utilisation réelle des ressources, en comparaison avec le plan; raisons des écarts enregistrés;
  • jalons réels atteints, en comparaison avec le plan; raisons des écarts enregistrés;
  • plan détaillé de l'étape de mise en place, avec renvoi aux activités suivantes :
    • conversion des fichiers, y compris tout rapprochement et échantillonnage des résultats;
    • formation, y compris les calendriers et la distribution des documents;
    • distribution des manuels d'utilisation et des manuels d'opérations;
    • redéploiement du personnel;
    • calendrier de mise en service;
  • budget mis à jour et raisons de tout changement;
  • calendrier mis à jour et raisons de tout changement;
  • analyse coûts/avantages mise à jour;
  • recommandation de continuer ou d'arrêter le projet.
Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.7.3 Vérifier l'utilisation réelle des ressources par renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.7.4 Vérifier si le budget et le calendrier mis à jour correspondent à l'analyse coûts/avantages mise à jour.

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.7.5 Comparer l'analyse coûts/avantages mise à jour à l'analyse coûts/avantages provenant de l'étape précédente et des documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 5.A.7.6 Déterminer si l'analyse coûts/avantages mise à jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critère : 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.

Étape de vérification : 5.A.8.1 Le document d'étape de l'étape de mise en oeuvre a-t-il été examiné par le comité directeur ou les détenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accepté?

Oui Non S/O Observations Renvois
         

Objectif : 5.B 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.

Étape de vérification : 5.B.1.1 Effectuer de nouveau certains tests de contrôle de l'intégrité des données.

Note : L'appendice I renferme des ouvrages de référence qui permettent de déterminer les techniques à utiliser pour effectuer de nouveau les contrôles choisis, selon la nature et l'environnement du système. Les systèmes en direct exploités en temps réels qui utilisent des systèmes de gestion de la base des données sous le contrôle d'une gestion administrative des données distinctes exigent de nouveaux tests plus complexes que les systèmes ordinaires de fichier maître sur bande avec entrée de lots.

Oui Non S/O Observations Renvois
         

Objectif : 5.C 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.

Étape de vérification : 5.C.1.1 Effectuer de nouveau certains tests de contrôle de l'intégrité du système.

Note : L'appendice I renferme des ouvrages de référence qui permettent de déterminer les techniques à utiliser pour effectuer de nouveau les contrôles choisis, selon la nature et l'environnement du système. Les systèmes en direct exploités en temps réel qui utilisent des systèmes de gestion de la base des données sous le contrôle d'une gestion administrative des données distincte exigent de nouveaux tests plus complexes que les systèmes ordinaires de fichier maître sur bande avec entrée de lots.

Oui Non S/O Observations Renvois
         





Annexe G : Programme de vérification de l'étape de la mise en place

Étape : 6. Mise en place

Objectif : 6.A. 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ère : 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.

Étape de vérification : 6.A.1.1 Examiner le plan de conversion avant son exécution en se rapportant à la liste des contrôles minimaux du traitement des systèmes et vérifier si des techniques de contrôle sont incluses dans le processus de conversion afin de répondre à toutes les questions de contrôle.

  • Il s'agit ici d'un processus extrêmement critique et on ne devrait tolérer aucun doute quant à l'intégrité des données dans les nouveaux fichiers. On peut devoir utiliser des techniques de contrôle telles que la vérification ligne à ligne.
Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.1.2 Vérifier que la conversion a été exécutée selon le plan établi.

Oui Non S/O Observations Renvois
         
Critère : 6.A.2 La formation a été assurée conformément au calendrier préparé à cet effet.

Étape de vérification : 6.A.2.1 Vérifier si la formation a été assurée selon le calendrier préparé lors de l'étape de mise en oeuvre et si toute variation a reçu l'accord de la gestion des clients.

Oui Non S/O Observations Renvois
         
Critère : 6.A.3 L'installation a été effectuée conformément au calendrier préparé à cet effet.

Étape de vérification : 6.A.3.1 Les mises en place ont-elles été faites selon le calendrier préparé lors de l'étape de mise en oeuvre? Les variations ont-elle été approuvées par la gestion des clients?

Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.3.2 L'acceptation formelle des utilisateurs selon le calendrier a- t-elle été obtenue? Par exemple, si l'on met en place des emplacements autonomes de traitement, de façon indépendante, chacun doit faire l'objet d'une signature d'approbation de la part de son utilisateur.

Oui Non S/O Observations Renvois
         
Critère : 6.A.4 Le rapport sur l'installation (ou un document de ce genre) examine le projet par rapport au budget et au calendrier contenu dans le rapport sur la phase de mise en oeuvre.

Étape de vérification : 6.A.4.1 Un rapport d'étape de l'étape de mise en place a-t-il été préparé et communiqué?

Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.4.2 Vérifier si ce document contient au moins les points suivants :

  • utilisation réelle des ressources, en comparaison avec le plan; raisons des écarts enregistrés;
  • jalons réels atteints, en comparaison avec le plan; raisons des écarts enregistrés;
  • budget mis à jour et raisons de tout changement;
  • calendrier mis à jour et raisons de tout changement;
  • analyse coûts/avantages mise à jour;
  • recommandation de poursuivre ou d'arrêter le projet.
Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.4.3 Vérifier l'utilisation réelle des ressources par renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.4.4 Vérifier si le budget et le calendrier mis à jour correspondent à l'analyse coûts/avantages mise à jour.

Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.4.5 Comparer l'analyse coûts/avantages mise à jour à l'analyse coûts/avantages provenant de l'étape précédente et aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 6.A.4.6 Déterminer si l'analyse coûts/avantages mise à jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critère : 6.A.5 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.

Étape de vérification : 6.A.5.1 Le caractère exact et complet du rapport d'étape de l'étape de mise en place et l'accord qu'il a entraîné doivent être reconnus à l'échelon approprié des utilisateurs et de la gestion de l'informatique.

Oui Non S/O Observations Renvois
         





Annexe H : Programme de vérification de l'étape des activités postérieures à la mise en place

Étape : 7. Activités postérieures à la mise en place

Objectif : 7.A Le système est exploité conformément aux objectifs d'analyse et autres critères d'évaluation, et si les coûts/avantages prévus sont atteints.

Critère : 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.

Étape de vérification : 7.A.1.1 Un rapport sur les activités postérieures à la mise en place, ou un document de ce genre, a-t-il été préparé?

Oui Non S/O Observations Renvois
         

Étape de vérification : 7.A.1.2 Vérifier si ce document contient les points suivants :

  • documentation des réalisations réelles du système;
  • comparaison de ces réalisations avec les objectifs originaux;
  • recommandation d'améliorations;
  • utilisation réelle des ressources, en comparaison avec le plan original; raisons des écarts enregistrés;
  • jalons réels atteints, en comparaison avec le plan; raisons des écarts enregistrés;
  • analyse coûts/avantages mise à jour.
Oui Non S/O Observations Renvois
         

Étape de vérification : 7.A.1.3 Vérifier l'utilisation réelle des ressources dans les documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 7.A.1.4 Comparer l'analyse coûts/avantages mise à jour aux documents sources.

Oui Non S/O Observations Renvois
         

Étape de vérification : 7.A.1.5 Déterminer si l'analyse coûts/avantages mise à jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         





Annexe I : Bibliographie

  1. The Chartered Institute of Public Finance and Accountancy. Computer Audit Guidelines. Londres : CIPFA, 1984.
  2. Gallegos, Richardson, et Bortheck. Audit and Control of Information Systems. Cincinnati : South-Western Publishing, 1987.
  3. Halper, Davis, O'Neil-Dunne et Pfau. Handbook of EDP Auditing. Boston : Warren, Gorham and Lamont, 1985.  Le chapitre 7 traite de l'élaboration des systèmes. Information supplémentaire dans une autre publication : le Handbook of EDP Auditing Supplements, 1986 et 1987, des mêmes auteurs.
  4. Institut canadien des comptables agrées. Guide pour le contrôle des systèmes informatiques. ICCA, 1986.
  5. Institute of Internal Auditors. Guidelines to Controls for Data Processing Environments. Altamonte Springs, Floride : IIA, 1983.
  6. Jenkins et Pinkney. An Audit Approach to Computers. Londres : Leighton-Straker, 1978.
  7. Mair, Wood et Davis. Computer Control and Audit. Altamonte Springs, Floride : The Institute of Internal Auditors. 1984.
  8. Rothberg. Structured EDP Auditing. Belmont, Californie : Lifetime Learning Publications, 1983.  Note : Tous les ouvrages ci-dessus sont disponibles au Centre de documentation en vérification du BCG.
  9. Auerbach. A Standard For Auditing Computer Applications Using Audit Software Packages. Boston : Warren, Gorham and Lamont.
  10. Auerbach EDP Publications Inc. Auerbach EDP Auditing. Ponnsouhen, New Jersey, 08109.
  11. Boar, Bernard H. Application Prototyping : A Project Management Perspective. New York : American Management Association, 1985.
  12. Boar, Bernard H. Application Prototyping; A requirement. Toronto : John Willey and Sons, 1984.
  13. Bureau du vérificateur général. Vérification de l'informatique : planification de la vérification de l'informatique.
  14. DMR Group, Information System Delivery Series, Prototyping Guide, Ottawa, 1987.
  15. EDP Auditor's Foundation. Control Objectives.
  16. Fitzgerald, Jerry. Designing Controls into Computerized Systems.
  17. FTP Technical Library. Auditing Computer Systems, vol. III., 492 Old Town Road, Port Jefferson Station, New Jersey, 11776.
  18. Gane, Christopher P. Structured System Analysis : Tools and Techniques. New York : Improved Systems Technologies, 1977. 2e édition : Englewood Cliffs, New Jersey : Prentice-Hall, 1979.
  19. The Institute of Internal Auditors. Managing the Information Systems Audit, A Case Study.
  20. Kuong, Javier F. Control for Advanced On-line/ Data-Base Systems. Wellesley Hills, Massachusetts : Management Advisory Publications (P.O. Box 151-44 Washington Street, Wellesley Hills, Mass., 02181). La 2e partie est aussi disponible.
  21. Lowry, Christina et Little, Robert. The Perils of Prototying, Volume 8, Numéro 4. Ann Arbor, Michigan : University of Michigan, 1985.
  22. MacEwan, Glenn H. Specification prototyping. Kingston : Queen's University, Department of Computing and Information Science, 1982.
  23. Martin, James. Security Accuracy, and Privacy in Computer Systems. Englewood Cliffs, New Jersey : Prentice-Hall, 1973.
  24. Martin, James. Strategic Data Planning Methodologies. Englewood Cliffs, New Jersey : Prentice-Hall, 1982.
  25. Perry, William E. Ensuring Data Base Integrity. New York : John Wiley and Sons, 1983.
  26. Roder, Martha H. et Stroka, John M. Prototyping Increases Chance of Systems Acceptance. Data Management Magazine, mars 1985.
  27. Willson et Root. Internal Auditing Manual. Boston : Warren, Gorham and Lamont.  Voir chapitre 6.
  28. Yourdon, Edward. Managing the Structured Techniques. 2e édition. New York : Yourdon Press, 1979.

 




Appendix J : Politiques et normes du CT et du BCG

Conseil du trésor et bureau du controleur général politiques et normes applicables aux systemes en cours d'élaboration

Aperçu de la politique de gestion de l'information - Orientation stratégique en matière de gestion de la technologie de l'information dans le gouvernement fédéral 1987

  • Conseil du Trésor

Circulaires du Conseil du Trésor:

  • 1980-33 Informatique - faire ou faire faire
  • 1982-17 Procédures - faire ou faire faire en informatique
  • 1983-36 Approbation des projets d'élaboration de systèmes informatiques
  • 1985-8 Politique sur les micro-ordinateurs
  • 1987-47 Politique concernant ls normes sur la technologie de l'information
  • 1987-52 Examen de la mise en oeuvre de la politique sur la sécurité
  • 1988-25 Élaboration, acquisition et exploitation de logiciels pour les systèmes de gestion financière

Élaboration de systémes financiers:

Critéres communs d'évaluation des sytémes de gestion financière (CGC 1197)

  • Bureau du contrôleur général
  • 1988

Modules du Manuel des systèmes de gestion financière, Bureau du contrôleur général : 

  • Gestion des recettes 1989 (CGC 1193)
  • Gestion des dépenses (CGC 1207)
  • Planification financière et budgétisation (à venir)

Direction de l'information et des systèmes de gestion financière - Méthodologie d'appréciation des risques

  • Bureau du contrôleur général
  • 1989

Ébauche: Factors for the Successful Implementation of a Financial Systems

  • Direction de l'information et des systèmes de gestion financière
  • Bureau du contrôleur général
  • 1989
  • l'ébauche n'a pas été traduite

Diapositives: Stratégie d'information financière à compter des années 90

  • Direction de l'information et des systèmes de gestion financière
  • Bureau du contrôleur général
  • 1989

Voir aussi Circulaire du Conseil du Trésor, no 1988-25 ci-dessus

Guide de vérification du processus de gestion

  • Bureau du contrôleur général
  • 1987

Guide de vérification des systèmes en cours d'élaboration

  • ébauche
  • Bureau du contrôleur général
  • 1988

Manuel de la politique administrative - chapitre 440 - Informatique

  • Conseil du Trésor
  • 1978

Manuel de la politique administrative - chapitre 540 - Gestion et contrôle des projets 

  • Conseil du Trésor
  • 1978

Normes de vérification dans le gouvernment du Canada (CGC 1009)

  • Bureau du contrôleur général
  • 1982

Normes et politique de sécurité

  • Secrétariat du Conseil du Trésor
  • 1989

Notice d'interprétation de la politique: Vérification avant la mise en oeuvre

  • NIP 1984-03
  • Bureau du contrôleur général

Politique du gouvernement sur la sécurité

  • Conseil du Trésor
  • 1987

Sécurité au gouvernement du Canada - Normes provisoires de sécurité

  • Conseil du Trésor
  • 1987