Cette page a été archivée.
Information archivée dans le Web à  des fins de consultation, de recherche ou de tenue de documents. Cette dernière n’a aucunement été modifiée ni mise à  jour depuis sa date de mise en archive. Les pages archivées dans le Web ne sont pas assujetties aux normes qui s’appliquent aux sites Web du gouvernement du Canada. Conformément à  la Politique de communication du gouvernement du Canada, vous pouvez demander de recevoir cette information dans tout autre format de rechange à  la page « Contactez-nous ».
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
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
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 :
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.
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 :
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.
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.
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)
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
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 :
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
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.
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.
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.
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 :
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 :
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.
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.
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 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.
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é.
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) :
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
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 |
|
|
Faisabilité |
|
|
Conception générale |
|
|
Conception détaillée |
|
|
Elaboration |
|
|
Mise en oeuvre |
|
|
Activités postérieures à la mise en place |
|
|
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.
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é.
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 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.
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 :
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.
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 :
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.
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é.
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.
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.
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
Ce chapitre traite du processus de vérification devant être appliqué à chaque étape d'un projet d'élaboration. L'expression « étape » a été retenue pour chacune des composantes chronologiques du CES dans le présent guide pour éviter la confusion avec l'expression « phase » utilisée en vérification.
La vérification des systèmes en cours d'élaboration a trois objectifs principaux : donner un avis sur l'efficience, l'efficacité et l'économie de la gestion du projet; donner un avis sur le degré auquel le système en cours d'élaboration fournit des pistes de vérification et des contrôles suffisants pour assurer l'intégrité des données traitées et stockées; et donner un avis sur les contrôles exercés pour la gestion du fonctionnement du système. Ces objectifs sont clairement identifiés dans le chapitre 3, à l'intention des vérificateurs, par un A (Contrôle des activités liées au projet), un B (Contrôle de la validité des données), ou un C (Contrôle des opérations du système) comme deuxième indicateur dans les parties relatives aux objectifs, aux critères et aux critères détaillés.
Pour atteindre le premier objectif, le vérificateur assiste aux réunions du comité de projet et du comité directeur, examine la documentation des contrôles du projet et effectue des entrevues. L'accent est mis sur l'établissement, avec le concours de l'entité vérifiée, de normes de contrôle du projet (p. ex., un processus formel d'élaboration des systèmes) et la détermination du degré d'observation de ces normes. Pour exécuter cette activité, le vérificateur doit garder présentes à l'esprit les exigences de l'ancien chapitre 440 du Manuel de la politique administrative du Conseil du Trésor, le contenu de toutes les circulaires, politiques et normes données à l'appendice J, ainsi que la documentation couverte par le Guide de vérification du processus de gestion du BCG.
Pour le deuxième objectif, le vérificateur se limite à examiner la documentation sur le système, comme les spécifications fonctionnelles, pour se former une opinion sur les contrôles. Cette opinion sera fondée sur la mesure dans laquelle le système de technologie de l'information répond aux objectifs généraux en matière de contrôle. Une liste de ces objectifs devrait être fournie à l'entité vérifiée. Il en va de même pour le troisième objectif, les contrôles opérationnels du système. Le vérificateur devrait fournir à l'entité vérifiée une liste des contrôles standard, en ce qui a trait aux questions opérationnelles, comme le délai de réponse, l'utilisation de l'unité centrale, et la disponibilité de l'espace d'accès direct, qu'il a utilisées comme critère d'évaluation.
La vérification d'un système en cours d'élaboration demande l'exécution de certaines procédures à chaque étape du CES. Bien que cette méthode semble segmenter le processus en vérifications séparées et distinctes, ce n'est pas le cas; la vérification d'une étape ou d'un groupe d'étapes doit tenir compte de toutes les vérifications antérieures (ou de l'absence de vérification) effectuées dans le processus continu d'élaboration d'un système.
Pour effectuer la vérification des systèmes en cours d'élaboration, les activités suivantes, communes à toutes les vérifications faites selon les normes du Conseil du Trésor, doivent figurer à chacune des phases de la vérification :
Les activités qui précèdent se tiendront pour la plupart à l'occasion d'une vérification de système en cours d'élaboration, avec une certaine variation dans leur application.
Toutes les phases de la vérification d'un CES doivent être planifiées et incluses dans la planification initiale de la vérification d'un système en cours d'élaboration. A mesure que la vérification du CES avance, le plan de vérification doit préciser quelle étape fait l'objet de la vérification et mettre à jour les plans visant les autres étapes.
L'activité d'examen et d'évaluation sera poursuivie à chacune des phases de vérification pour vérifier si le système suit le processus du CES. Cependant, puisqu'on commence à documenter et à programmer les contrôles au cours de l'étape de faisabilité, l'examen et l'évaluation de l'intégrité des données et des contrôles du système ne peuvent être effectués qu'aux phases de l'étude de faisabilité, d'analyse générale, d'analyse détaillée, de mise en oeuvre, de mise en place et de vérification des activités postérieures à la mise en place.
Tout au long du processus d'élaboration, le vérificateur vérifiera la conformité de celui-ci avec le CES (voir l'approche détaillée en 4.A.10.1). Le vérificateur ne testera pas les contrôles mais examinera plutôt leur conformité avec les normes de test pour le CES. Là où les tests n'ont pas été suffisants, le vérificateur doit immédiatement en aviser les gestionnaires du projet. Les tests sont une fonction se rapportant à l'utilisateur et à l'équipe de projet. La participation directe du vérificateur à l'exécution des tests peut compromettre son objectivité, mais il peut décider d'effectuer certains tests à nouveau, afin d'appuyer les conclusions du contrôle.
Une caractéristique importante des vérifications des systèmes en cours d'élaboration est que l'on y évite un rattrapage coûteux des contrôles, ce qui ne peut toutefois être réalisé que là où la communication entre le vérificateur et le service vérifié permet de prendre rapidement des mesures pour corriger les points relevés par la vérification. Pour bien servir les intérêts de la haute direction, les rapports de vérification doivent suivre le processus d'élaboration du système. Toutefois, dès qu'il peut les étayer, le vérificateur doit également communiquer ses constatations à une personne au niveau de gestionnaire de projet. Pour garantir l'objectivité de la vérification et tenir la haute direction au courant des activités de la vérification des systèmes en cours d'élaboration, la présentation de rapports sommaires de vérification devrait coïncider avec les étapes du projet et les points de contrôle. Par exemple, le processus peut prévoir les étapes ci- dessous :
Dans ce cas, les sorties de vérification comporteraient un protocole de plan de vérification devant être présenté à tous les niveaux de gestion pendant la vérification de l'étape de lancement du projet ainsi que des rapports sommaires de vérification, selon le processus ordinaire de présentation de rapports de vérification, après chacune des étapes de vérification suivantes.
Par ailleurs, les activités de vérification des systèmes en cours d'élaboration doivent être prévues de manière à aider les hauts fonctionnaires lorsque les présentations au Conseil du Trésor doivent être approuvées par le ministère. Habituellement, le vérificateur émet un avis sur le caractère raisonnable des renseignements sur les coûts/avantages que renferme la présentation, mais il peut également entamer une vérification d'autres renseignements contenus dans la présentation.
Les études de CES présentées ci-dessus s'appliqueraient surtout aux nouveaux systèmes majeurs en cours d'élaboration ou à des changements importants apportés aux systèmes existants. Dans l'élaboration des systèmes plus petits, ou lorsque des changements mineurs sont apportés à des systèmes existants, on peut regrouper les étapes de CES ou en abandonner quelques-unes. Dans ce dernier cas, l'équipe de projet doit faire particulièrement attention à ne pas léser le système. Par exemple, si l'on ne prend pas suffisamment les solutions de rechange en considération dans l'étape de faisabilité, il peut en résulter la sélection d'une solution de rechange inappropriée. Le facteur coûts, lorsqu'il est décidé d'abandonner une étape, doit être considéré en regard du risque encouru.
La création de prototypes a été décrite au chapitre 2. Les questions et les contrôles se rapportant à cette technique sont compris dans les étapes de lancement et de faisabilité qui suivent.
Les projets de mise-à-jour, c'est-à-dire les améliorations apportées aux systèmes déjà en place, peuvent être considérés comme assez importants pour être envisagés comme des projets de CES complets en eux-mêmes. Les points de vérification seraient alors identiques à ceux décrits ci-dessous.
On doit définir des normes d'élaboration pour chaque étape du CES et s'y tenir pour assurer une cohérence dans l'élaboration de tous les projets des ministères. Néanmoins, un ministère donné pourrait définir un ensemble séparé de normes fondées sur le genre de projet qui est entrepris (élaboration de système majeur ou mineur), ce qui contribuera à assurer que des normes minimales sont appliquées dans les activités d'élaboration des systèmes mineurs.
Finalement, lorsqu'il établit si un système est assez petit pour justifier le regroupement ou l'élimination de certaines étapes du CES d'une vérification, le vérificateur doit garder à l'esprit que certains changements relativement mineurs peuvent être très importants du point de vue des contrôles. L'importance d'une modification apportée à un système doit être évaluée avec soin si l'on pense à s'écarter des normes.
Voici maintenant les objectifs de contrôle, les critères et les critères détaillés se rapportant à chaque étape d'élaboration de projets pour le contrôle des activités liées au projet (A), le contrôle de la validité des données (B) et le contrôle d'opérations du système (C).
Les premiers contrôles sont naturellement examinés à chaque étape d'élaboration afin que l'on puisse se faire une opinion sur l'efficience, l'efficacité et l'économie de l'exécution du projet. Heureusement les contrôles de l'entrée, de l'intégrité des données et de la gestion du système peuvent n'être examinés que lors des étapes d'étude de faisabilité, d'analyse générale, d'analyse détaillée et de mise en oeuvre, afin de permettre des données de vérification opportunes (voir figure 4). L'étape d'étude de faisabilité est incluse, pour le cas où les exigences en matière de contrôle peuvent se rapporter au choix d'une approche d'analyse.
Il est à noter que si certains critères de contrôle des projets sont répétés d'une étape de vérification à une autre, le vérificateur doit traiter chaque phase de vérification du guide comme une phase distincte. Cela signifie qu'il doit tenir compte des objectifs de toutes les phases de vérification antérieures à la phase où il est rendu lorsqu'il détermine quels objectifs appliquer à la phase de vérification.
Finalement, les sections du chapitre sont identifiées par des chiffres et des lettres qui permettent au lecteur de savoir à quelle phase et à quel objectif de vérification il est rendu dans le texte. Le diagramme qui suit permet de bien comprendre le système d'identification :
Figure 4 : Activités de vérification pour chaque étape d'élaboration
Étape | Projet | Données | Systeme |
---|---|---|---|
Lancement | OUI | NON | NON |
Étude de faisabilité | OUI | OUI | OUI |
Conception générale | OUI | OUI | OUI |
Conception détaillé | OUI | OUI | OUI |
Mise en oeuvre | OUI | OUI** | OUI* |
Mise en place | OUI | NON | NON |
Activités postérieures à la mise en place | OUI | OUI** | OUI** |
OUI signifie qu'une activité de vérification doit avoir lieu à ce stade.
NON signifie qu'aucune activité de vérification ne doit avoir lieu à ce stade.
* Les contrôles du système font partie de l'examen des essais effectués lors de cette phase. (Voir le critère 5.A.3.2 à l'appendice F).
** Comprend la réexécution de certains tests de contrôle.
Les renseignements de vérification que renferme le reste du chapitre et les appendices connexes sont identifiés au moyen d'un numéro de classification Dewey à quatre zones (voir la figure 5). Grâce à ce numéro, le lecteur pourra savoir où il est rendu dans le texte.
Figure 5 : Exemple du Système de classification Dewey
1.A.1.1
Étapes du ces :
1.A.1.1
Objectifs :
A = Contrôle des activités liées au projet
B = Contrôle de la validité des données
C = Contrôle d'opérations du système
1.A.1.1
Critères
1.A.1.1
Procédures de vérification
Il est essentiel que la participation du vérificateur soit communiquée officiellement au comité directeur des systèmes du ministère, ce qui s'effectuera par l'entremise d'un protocole formel stipulant la nécessité de la présence du vérificateur aux réunions de l'équipe de projet et du comité directeur.
Après que le vérificateur aura terminé la phase de planification de la vérification de l'étape de lancement, un protocole formel pour le plan de vérification sera publié, indiquant la participation des vérificateurs pour le reste du projet.
On examinera la conformité avec les exigences du CES pendant cette étape et on transmettra au comité directeur tout écart majeur.
L'expression « utilisateur ou direction des utilisateurs » utilisée dans les objectifs, les critères ou les critères détaillés signifie la « collectivité des utilisateurs », habituellement représentée par un ou plusieurs membres de l'équipe de projet. La « collectivité des utilisateurs » peut représenter une ou plusieurs entités distinctes au sein du ministère. Le vérificateur doit veiller à la juste représentation de la « collectivité » au sein de l'équipe.
On doit justifier clairement l'entreprise d'un nouveau processus d'élaboration, généralement par une analyse économique; cependant, dans certains cas, on peut le faire en évaluant le besoin de services améliorés ou supplémentaires, ou d'autres préoccupations non quantifiables. Quoi qu'il en soit, il doit exister une forme quelconque de justification du projet.
La documentation des contraintes s'appliquant au projet (dans les documents relatifs à celui-ci) et l'identification préliminaire des conditions qui serviront à mesurer l'efficacité du nouveau système garantissent que la décision de lancer le projet a été prise après considération de l'information nécessaire.
Le contrôle, l'organisation, les responsabilités et les autorités s'appliquant au projet doivent être établis clairement.
On doit intégrer au plan de vérification des activités de vérification visant à traiter des risques principaux suivants, qui pourraient empêcher que les exigences de l'utilisateur ou du projet soient satisfaites :
1.A Déterminer si le projet a été lancé officiellement et si des contrôles adéquats sont exercés.
1.A.1 Le rapport sur le lancement du projet (ou un document semblable) indique que le projet est nécessaire.
1.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données jugent le projet nécessaire.
1.A.3 Le rapport sur le lancement du projet indique l'organisation du projet.
1.A.4 Le rapport sur le lancement du projet indique les étapes de réalisation du projet ainsi que les tâches et les responsabilités.
1.A.5 Le rapport sur le lancement du projet renferme un plan de travail qui indique, notamment, les délais fixés.
1.A.6 L'organisation du projet, les étapes de réalisation et le plan de travail ont été approuvés officiellement par un gestionnaire de niveau approprié.
Note 1 : Cet objectif et les critères qui s'y rapportent correspondent aux programmes de vérification de l'appendice B qui portent le même nom.
Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun objectif relatif au contrôle de la validité des données (B) ou au contrôle des opérations du système (C) pour l'étape de lancement (1) puisqu'il n'est pas nécessaire de documenter les contrôles à cette étape (voir la figure 3).
Lors de l'étape de lancement du projet, le problème a été décrit. L'objectif de cette étape est donc d'étudier les exigences des utilisateurs en général afin de déterminer la solution conceptuelle qui convient, en termes de compatibilité organisationnelle, de justification économique et d'adaptation technique. On préparera des spécifications détaillées lors de l'étape suivante en s'appuyant sur ces exigences, généralement regroupées dans le DOCUMENT DES EXIGENCES DE L'UTILISATEUR.
Le vérificateur doit s'assurer que les exigences de l'utilisateur ont été relevées et documentées en détail. L'équipe du projet doit réunir avec grand soin l'information contenue dans le document sur les exigences des utilisateurs grâce à ceux d'entre eux qui, ne connaissant pas le potentiel d'un nouveau système, ne limitent pas pour autant leur définition des exigences.
Toutes les solutions de rechange pratiques doivent avoir été relevées et analysées. Les faits et les évaluations coûts/avantages utilisés dans l'analyse doivent être raisonnables et provenir de sources fiables. Les conclusions doivent être la suite logique de l'analyse.
Les évaluations des ressources et du temps nécessaires doivent être complètes et raisonnables. Du fait que ces évaluations serviront au contrôle budgétaire et au contrôle du projet, il est impératif que toute l'information soit convenablement détaillée.
On doit intégrer au plan de vérification des activités liées aux risques principaux suivants :
2.A Déterminer si une étude de faisabilité (y compris un plan de projet global) a été réalisée dans le but de trouver la solution idéale à un problème donné du point de vue organisationnel, économique et technique.
2.A.1 Le rapport sur les besoins des utilisateurs (ou un document de ce genre) examine les besoins des utilisateurs.
2.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que la définition des besoins est précise et complète.
2.A.3 L'étude de faisabilité (ou un document de ce genre) renferme une analyse des solutions de rechange.
2.A.4 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'analyse des solutions de rechange est fondée sur des données précises et complètes, y compris les contraintes et les risques, et approuvent les recommandations formulées.
2.A.5 Le rapport sur l'analyse coûts/avantages (ou un document semblable) renferme une estimation des ressources humaines et financières requises.
2.A.6 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'analyse des coûts/avantages est fondée sur des données précises et complètes, et approuvent la solution de rechange recommandée.
2.A.7 Le gestionnaire responsable du projet s'est inspiré de la solution de rechange recommandée dans l'analyse des coûts-avantages pour préparer un sommaire des aptitudes personnelles :
2.A.8 Les comptes rendus des réunions du comité directeur ou des documents de ce genre.
2.A.9 Le rapport sur l'étude de faisabilité (ou un document de ce genre) compare l'état d'avancement du projet au plan de travail contenu dans le rapport sur le lancement du projet.
2.A.10 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que l'étude de faisabilité (ou un document semblable) est fondée sur des données précises et complètes, et l'approuvent ou jugent que les problèmes ont été réglés à leur satisfaction.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice B qui portent le même nom.
Dans cette étape d'élaboration, l'utilisateur, qui est en fin de compte responsable de l'intégrité des données, doit faire connaître ses exigences se rapportant au contrôle de la validité des données (B). Ces exigences doivent être prises en considération au moment de mener l'étude de faisabilité et l'analyse coûts/avantages afin d'assurer leur inclusion dans le système. Les exigences se rapportant au traitement et au contrôle de la sécurité ou de la protection des renseignements personnels doivent être incluses dans le document des exigences de l'utilisateur, ou le prototype équivalent.
Les contrôles d'opérations du système (C) sont les contrôles nécessaires pour s'assurer que le système continue à fonctionner de façon efficiente et efficace après sa mise en place. Ces contrôles diffèrent des contrôles sur les données et l'information et ont des objectifs différents. Les contrôles de la gestion, portant sur le fonctionnement du système, doivent correspondre à la définition des exigences pour le système lui-même et à l'analyse coûts/avantages.
On doit intégrer au plan de vérification des activités de vérification liées aux risques principaux suivants :
2.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées, et si des mesures de sécurité, de protection des renseignements personnels et d'accès à l'information sont prévues.
2.B.1 La fiche de contrôle (ou un document de ce genre) indique les mesures de contrôle prévues.
2.B.2 Le représentant des utilisateurs a pris bonne note du niveau de sécurité, de protection des renseignements personnels et d'accès à l'information des données emmagasinées par le système; et sait dans quelle mesure le système et les données sont sensibles en cas de perte, de destruction, d'accès non autorisé et de modifications.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice C qui portent le même nom.
2.C S'assurer que les contrôles en place assurent le fonctionnement efficient, efficace et économique du système.
2.C.1 La configuration de base (ou un document de ce genre) fait état des exigences en matière de contrôle de la gestion du système.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice C qui portent le même nom.
A cette étape, on prépare des spécifications détaillées des exigences de l'utilisateur à partir de la solution de rechange au système conçu qui a été approuvée à l'étape précédente. Les spécifications qui en résultent sont exprimées dans les termes de ceux qui remplissent les fonctions de gestion visées et sont libres de tout point d'analyse technique. Les spécifications fonctionnelles seront traduites en une analyse de système à l'étape suivante.
Les questions de sécurité doivent demeurer une préoccupation de la vérification à cette étape, ainsi qu'on l'a noté à la fin du chapitre 2.
On doit avoir surveillé la performance des projets pendant l'étape de conception générale, par rapport aux plans et budgets établis lors de l'étape de faisabilité, et justifier les écarts auprès des autorités de projets.
Le système, dans son analyse, doit répondre aux exigences des utilisateurs. Les points concernant les contrôles (financier et opérationnel) doivent avoir été traités. Dans certains cas, le mandat de la vérification peut demander l'évaluation de ces contrôles d'application.
On doit s'être occupé des éléments manuels et automatisés du nouveau système.
La documentation doit traiter suffisamment en détail de tous les éléments du système pour permettre une analyse détaillée du système.
Dans le plan de vérification, on doit prendre en considération les risques principaux suivants :
3.A S'assurer que la conception générale du système est fondée sur les constatations de l'étude de faisabilité, qu'elle produit une description fonctionnelle du manuel d'instructions et des procédés informatiques, et qu'elle donne lieu à la conception d'un système permettant d'obtenir un engagement quant à la poursuite de l'élaboration.
3.A.1 Le rapport sur la configuration du système (ou un document de ce genre) fait état des caractéristiques du système.
3.A.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que la configuration du système est précise et complète.
3.A.3 Le dictionnaire ou répertoire des données a été mis à jour en fonction de la configuration du système.
3.A.4 Toutes les ressources humaines nécessaires ont été affectées à la réalisation du projet.
3.A.5 Le calendrier des réunions du comité directeur (ou un document de ce genre) indique la date des réunions prévues, ainsi que les questions qui seront à l'ordre du jour.
3.A.6 Le rapport sur l'analyse générale (ou un document de ce genre) renferme une étude du projet par rapport au budget et au calendrier contenus dans l'étude de faisabilité.
3.A.7 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que le rapport sur l'analyse générale est complet et précis, et l'approuvent.
3.A.8 Une analyse de l'incidence sur les ressources humaines est planifiée.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.
L'équipe de projet, composée de représentants des utilisateurs et de l'informatique, doit choisir les techniques permettant de satisfaire aux exigences en matière de contrôle élaborées lors de l'étape de faisabilité. Cette sélection n'est limitée que par l'imagination des membres de l'équipe. Le travail du vérificateur à ce point consiste à évaluer le contrôle, et non les capacités techniques des utilisateurs.
Les activités de vérification intégrées au plan de vérification doivent tenir compte des risques principaux qui suivent :
3.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées.
3.B.1 Afin de satisfaire aux exigences énoncées dans la liste des contrôles la configuration du système (ou un document semblable) énonce les méthodes de contrôle du traitement des données.
3.B.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que les méthodes de contrôle du traitement des données sont complètes et précises.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.
3.C Déterminer si le système fonctionnel est exploité de façon efficace et efficiente.
3.C.1 Afin de satisfaire aux exigences énoncées dans la liste des contrôles, la fiche de contrôle de gestion (ou un document de ce genre) énonce les méthodes de contrôle de la gestion du système.
3.C.2 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que les méthodes de contrôle de la gestion du système sont complètes et précises.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice D qui portent le même nom.
Pendant l'étape d'analyse détaillée, on traduit les spécifications fonctionnelles préparées aux étapes précédentes en une description du système qui permettra de répondre aux exigences fonctionnelles spécifiées. L'analyse du système sera alors mise en oeuvre dans des systèmes informatisés et manuels lors de l'étape de mise en oeuvre.
Le principal objectif de cette étape est de traduire les spécifications d'analyse des utilisateurs en systèmes, processus de bases de données qui fonctionneront dans le cadre des contraintes de matériel et de logiciels des systèmes.
On devrait avoir surveillé la performance du projet à l'étape d'analyse détaillée, par rapport aux plans et budgets établis lors de l'étape de faisabilité (ou leur révision subséquente), et justifié les écarts auprès des autorités du projet.
Tous les éléments du système devront avoir été conçus en détail. Les éléments manuels et informatisés, ainsi que les caractéristiques de contrôle du système devront avoir été envisagés.
Si le mandat de vérification comprend l'évaluation des contrôles d'application, un examen, décrit dans le Guide de la vérification des contrôles d'application peut se révéler nécessaire.
L'analyse détaillée est l'analyse complète et finale du système opérationnel, c'est-à-dire qu'il ne doit y avoir aucun défaut ou aucune incohérence technique apparent. Selon le mandat de vérification, le vérificateur peut examiner les preuves que cela a été établi ou s'en assurer directement grâce à une réexécution de l'évaluation.
Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :
4.A Déterminer si une conception détaillée a été mise au point à partir des caractéristiques fonctionnelles établies au moment de la conception générale.
4.A.1 Le rapport sur la conception détaillée (ou un document de ce genre) fait état des caractéristiques de la programmation.
4.A.2 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que les caractéristiques sont précises et complètes.
4.A.3 Le dictionnaire ou répertoire des données a été mis à jour en fonction du document sur les caractéristiques de la conception détaillée.
4.A.4 Le plan de mise à l'essai (ou un document de ce genre) indique les mises à l'essai prévues.
4.A.5 Les utilisateurs au niveau approprié et les gestionnaires responsables du traitement des données estiment que le plan de mise à l'essai est précis et complet.
4.A.6 Le plan de mise à l'essai tient compte des besoins des utilisateurs.
4.A.7 Toutes les ressources humaines requises ont été affectées à la réalisation du projet.
4.A.8 Le calendrier des réunions du comité directeur (ou un document de ce genre) fait état de toutes les réunions prévues, ainsi que des questions qui seront à l'ordre du jour.
4.A.9 Le rapport sur la conception détaillée (ou un document de ce genre) examine le projet par rapport au budget et au calendrier établis dans le rapport sur la conception générale.
4.A.10 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la conception détaillée renferme des données précises et complètes, et s'ils l'approuvent.
4.A.11 Une analyse de l'incidence sur les ressources humaines a été effectuée.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.
A ce stade de la conception détaillée, les techniques de contrôle de l'application relevées lors de l'étape précédente ont été transformées en contrôles des entrées, du traitement et des sorties.
A beaucoup d'égards, la vérification des contrôles de la gestion des données et des systèmes commence à ressembler à la vérification d'un système en activité. La principale différence est que le vérificateur doit vérifier les tests de l'équipe de projet et ne devrait réexécuter les tests de contrôle que de façon sélective.
Les contrôles d'entrées porteront sur la transmission, l'acceptation, la conversion et la validation des données, ainsi que sur la correction des erreurs. Les contrôles du traitement porteront sur la restriction à l'accès et la vérification de l'intégrité des données entre les étapes du traitement et à l'intérieur des bases de données. Ils minimiseront également l'incidence des pannes des systèmes sur les systèmes en direct. Les contrôles des sorties consistent en un rapprochement et un équilibrage généralisés des fichiers des sorties et des rapports, et portent sur les mesures de sécurité connexes.
Jusqu'à un certain point, la nature des contrôles d'application mis au point sera fonction de leur application à un système particulier. Par conséquent, il n'est pas pratique d'essayer de prévoir l'inclusion des spécifications détaillées de l'analyse des systèmes se rapportant à chaque technique de contrôle. Là encore, l'appendice I contient des renvois à des ouvrages traitant de la vérification des systèmes en activité. En plus d'examiner les tests à entreprendre par l'équipe de projet pour vérifier que ces tests couvrent bien les exigences en matière de contrôle, le vérificateur doit commencer à relever les contrôles devant être testés à nouveau (A NOUVEAU et non pour la PREMIERE FOIS), après que l'on dispose des premiers programmes, c'est-à-dire probablement à la fin de l'étape de mise en oeuvre ou au début de l'étape de mise en place.
On doit intégrer au plan de vérification des activités de vérification qui traitent du risque principal suivant :
4.B Déterminer si les données traitées et emmagasinées par le système sont complètes, précises et dûment autorisées.
4.B.1 Déterminer si le plan de mise à l'essai (ou un document de ce genre) fait état des méthodes de contrôle du traitement énoncées dans le rapport sur le contrôle du traitement.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.
4.C Déterminer si le système est exploité de façon efficace et efficiente.
4.C.1 Déterminer si le plan de mise à l'essai (ou un document de ce genre) fait état des méthodes de contrôle nécessaires pour respecter les exigences énoncées dans le rapport sur le contrôle de gestion du système.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice E qui portent le même nom.
Le système en cours d'élaboration est mis en oeuvre dans des systèmes informatisés et manuels devant être opérationnels lors de l'étape suivante, d'après les spécifications de l'analyse des systèmes documentées dans les étapes précédentes.
Des programmes informatiques et des procédures manuelles sont rédigés et testés. Des documents de formation et le calendrier de mise en place sont préparés.
On doit avoir surveillé la performance du projet pendant l'étape de mise en oeuvre, par rapport aux plans et aux budgets établis lors de l'étape de faisabilité (ou leurs révisions subséquentes), et justifié les écarts auprès des autorités de projets.
Les tests des systèmes et programmes doivent être complets et entièrement documentés. Les problèmes rencontrés doivent avoir été réglés. Le vérificateur peut choisir de réexécuter certains tests de façon sélective, mais ne doit jamais être perçu comme étant responsable des tests.
Les manuels d'utilisations, les formats des entrées et des sorties, la présentation sur l'écran et toute autre forme d'interface avec l'utilisateur doivent être conçus pour optimiser leur efficacité.
Les activités de vérification à intégrer au plan de vérification couvrent les risques principaux suivants :
5.A Déterminer si tous les formulaires, manuels, programmes et documents de formation appropriés ont été préparés à partir des spécifications détaillées de la conception.
5.A.1 Tous les manuels et autres documents requis ont été préparés avant l'installation du système.
5.A.2 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que les manuels et les documents requis renferment des données complètes et précises.
5.A.3 Le rapport sur la mise à l'essai (ou un document de ce genre) fait état des résultats obtenus.
5.A.4 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la mise à l'essai renferme des données précises et complètes.
5.A.5 Toutes les ressources humaines nécessaires restent affectées à la réalisation du projet.
5.A.6 Le calendrier des réunions du comité directeur (ou un document de ce genre) indique la date de toutes les réunions prévues, ainsi que les questions qui seront à l'ordre du jour.
5.A.7 Le rapport sur la mise en oeuvre (ou un document de ce genre) examine le projet par rapport au budget et au calendrier établis durant l'analyse détaillée.
5.A.8 Les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur la mise en oeuvre renferme des données précises et complètes, et s'ils approuvent ce rapport.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.
Des contrôles sont intégrés au nouveau système, lors de cette étape, pour assurer l'intégrité des données et la gestion des systèmes. Les efforts principaux du vérificateur portent surtout sur la vérification des tests, traitée dans la partie qui précède, mais il existe maintenant une possibilité de réexécution sélective des tests pour les contrôles clés.
L'appendice I présente des documents de référence pour la détermination des techniques appropriées permettant de tester à nouveau les contrôles choisis, d'après la nature du système et son environnement. Les systèmes en direct à temps réel, faisant appel à des systèmes de gestion des bases de données sous le contrôle d'une gestion administrative des données séparées, exigeront de nouveaux tests plus complexes que les systèmes typiques à entrées par lots, ou à fichier maître sur bande magnétique. Le recours judicieux aux documents de référence permettra au vérificateur ayant une expérience suffisante en informatique d'exécuter de nouveaux tests efficients et efficaces.
On doit intégrer au plan de vérification des activités qui tiennent compte des risques principaux suivants :
5.B Déterminer si les principaux contrôles de transmission sont efficaces.
5.B.1 Exercer de nouveau certains contrôles de la validité des données.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.
5.C Déterminer si les principaux contrôles exercés sont efficaces.
5.C.1 Exercer de nouveau certains contrôles de la validité des données.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice F qui portent le même nom.
Lors de cette étape, le système devient opérationnel. La formation commence et les fichiers sont convertis.
Le système est mis en place d'après le plan élaboré lors de l'étape précédente, ce qui peut exiger un processus échelonné, p. ex. par emplacement géographique, par composante organisationnelle ou en fonction des besoins. Dans le dernier cas, la fixation de critères serait nécessaire. Une signature d'acceptation est demandée à l'utilisateur.
On doit avoir surveillé la performance du projet pendant l'étape de mise en place, par rapport aux plans et budgets établis lors de l'étape de faisabilité (ou leurs révisions subséquentes) et justifié les écarts auprès des autorités du projet.
La conversion des données doit être exacte. Les tests du processus de conversion des données doivent être bien documentés. D'après la qualité et l'exécution des tests exécutés par l'organisme vérifié, le vérificateur peut décider de réexécuter certains tests.
On doit envisager, lors de cette étape de vérification, des activités portant sur les risques clés suivants :
6.A Déterminer si le système et la conversion de fichiers (le cas échéant) passent du stade de développement au stade d'opération et d'entretien.
6.A.1 La précision, l'intégralité et l'authenticité des fichiers créés par voie de conversion sont assurées grâce à l'application des méthodes de contrôle appropriées.
6.A.2 La formation a été assurée conformément au calendrier préparé à cet effet.
6.A.3 L'installation a été effectuée conformément au calendrier préparé à cet effet.
6.A.4 Le rapport sur l'installation (ou un document de ce genre) examine le projet par rapport au budget et au calendrier contenus dans le rapport sur l'étape de mise en oeuvre.
6.A.5 Déterminer si les utilisateurs et les gestionnaires responsables du traitement des données estiment que le rapport sur l'installation renferme des données précises et complètes, et s'ils approuvent ce rapport.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice G qui portent le même nom.
Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun objectif pour les contrôles de la validité des données (B) et les contrôles d'opérations du système (C) à l'étape de la mise en place (6).
Pendant cette étape, le système sera en opération et sera soumis à des changements systémiques contrôlés afin de fonctionner de façon satisfaisante et selon les besoins courants. On doit préparer un rapport sur le projet, trois à six mois après la mise en place du système, pour indiquer son degré de conformité avec les exigences fonctionnelles des utilisateurs et le degré de conformité aux coûts/avantages prévus.
Les activités de vérification lors de cette étape comportent un examen du rapport de suivi et des documents de travail, par rapport à toute la documentation des étapes précédentes, afin d'assurer leur conformité avec le CES et d'attester le l'exactitude et l'intégrité des résultats observés.
On doit inclure dans le plan de vérification des activités portant sur les risques principaux suivants :
7.A Déterminer si le système est exploité conformément aux objectifs de conception et autres critères d'évaluation, et si les coûts/avantages prévus sont atteints.
7.A.1 L'installation a été suivie d'un examen et si les résultats ont été communiqués aux membres de la haute direction.
Note 1 : Cet objectif et les critères qui s'y rattachent correspondent aux programmes de vérification de l'appendice G qui portent le même nom.
Note 2 : Comme il est indiqué à la figure 4, il n'existe aucun
objectif pour les contrôles de la validité des
données (B) et les contrôles d'opérations du système
(C)
à l'étape des activités postérieures à la mise en
place (7).
É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 |
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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?
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 |
---|---|---|---|---|
Étape de vérification : 2.A.3.1 Une étude de faisabilité technologique a-t-elle été préparée et documentée?
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
Étape de vérification : 2.A.3.2 Vérifier si cette étude porte sur les points suivants :
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 |
---|---|---|---|---|
É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?
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 |
---|---|---|---|---|
É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.
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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
(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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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?
É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) :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
Étape de vérification : 5.A.1.1 Déterminer si les éléments suivants ont été préparés :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
Étape de vérification : 5.A.1.2 Vérifier si le manuel dutilisation :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
Oui | Non | S/O | Observations | Renvois |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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.
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
É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 |
---|---|---|---|---|
É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 :
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 |
---|---|---|---|---|
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
Circulaires du Conseil du Trésor:
Élaboration de systémes financiers:
Critéres communs d'évaluation des sytémes de gestion financière (CGC 1197)
Modules du Manuel des systèmes de gestion financière, Bureau du contrôleur général :
Direction de l'information et des systèmes de gestion financière - Méthodologie d'appréciation des risques
Ébauche: Factors for the Successful Implementation of a Financial Systems
Diapositives: Stratégie d'information financière à compter des années 90
Voir aussi Circulaire du Conseil du Trésor, no 1988-25 ci-dessus
Guide de vérification du processus de gestion
Guide de vérification des systèmes en cours d'élaboration
Manuel de la politique administrative - chapitre 440 - Informatique
Manuel de la politique administrative - chapitre 540 - Gestion et contrôle des projets
Normes de vérification dans le gouvernment du Canada (CGC 1009)
Normes et politique de sécurité
Notice d'interprétation de la politique: Vérification avant la mise en oeuvre
Politique du gouvernement sur la sécurité
Sécurité au gouvernement du Canada - Normes provisoires de sécurité