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

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

Avertissement Cette page a été archivée.

Information archivée dans le Web

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




Conseil du trsor du canada bureau du controleur gnral du canada

Sries 500 guide 507
Guide de vrification des systemes en cours d'laboration

Manuel de vrification interne
Volume iii
Guide de vrification interne

bauche de travail
mars 1991

Le Bureau du contrleur gnral (BCG) est un organisme qui offre des services bilingues. Soyez tout fait l'aise de communiquer avec nous dans la langue de votre choix.

Rdig au nom du Conseil du Trsor du Canada Contrleur gnral Comit consultatif interministriel de la vrification interne

Ottawa, Ontario
K1A 1E4



Table des matires

Avant-propos

Introduction

L'Environnement du processus d'laboration des systmes

Dtail du processus d'laboration des systmes

Excution de la vrification : la vrification applique au processus d'laboration des systemes

Annexe A : Grille des entrevues

Annexe B : Programme de vrification de l'tape de lancement du projet

Annexe C : Programme de vrification de l'tape de l'tude de faisabilit

Annexe D : Programme de vrification de l'tape de conception gnrale

Annexe E : Programme de vrification de l'tape de conception dtaille

Annexe F : Programme de vrification de l'tape de la mise en oeuvre

Annexe G : Programme de vrification de l'tape de la mise en place

Annexe H : Programme de vrification de l'tape des activits postrieures la mise en place

Annexe I : Bibliographie

Annexe J : Politiques et normes du CT et du BCG applicables aux systmes en cours d'laboration




Avant-propos

Ce guide a t produit par la :

Direction de la vrification et de l'examen
Bureau du Contrleur gnral

Il se fonde sur les documents qui y sont mentionns ici, de mme que sur l'exprience et les ides des participants suivants :

  • Direction de la politique administrative, SCT
  • Direction des vrifications de l'information et de la gestion, Groupe des services de vrification, Agence gouvernementale de consultation et de vrification
  • Direction de l'informatique et des systmes de gestion
    financire, BCG
  • Vrification de la gestion et valuation, Travaux publics Canada
  • Directeur gnral - Vrification, Dfense nationale
  • Vrification interne et valuation, Revenu Canada - Impt

 




Introduction

Historique

A la fin de l'anne 1983, le Bureau du Contrleur gnral dcidait, par suite de l'importance des premiers rsultats obtenus par le groupe de travail sur l'informatique, de suspendre la publication de la version prliminaire du Guide de vrification de la performance de l'laboration des systmes. Le groupe de travail avait t tabli par le Conseil du Trsor le 7 juillet 1983 et l'on avait alors pens que ses activits s'tendraient sur la priode des 12 18 mois suivants. Cependant, cette priode a vu la parution d'une Notice d'interprtation de la politique (NIP 1984-03) sur la Vrification avant la mise en oeuvre . C'est sur cette NIP que se fondent l'objet et la porte de ce guide.

Le rapport du groupe de travail a t publi en 1985 et le 22 juillet 1986 une premire rdaction de l'Aperu de la politique de gestion de l'information a t publie par la Direction de la politique administrative du Secrtariat du Conseil du Trsor, en partie en rponse ce rapport. Ces diffrents documents, tout en brossant un portrait clair des changements spectaculaires intervenus dans la technologie de l'laboration des systmes, soulignent aussi l'importance du contenu de la NIP au sujet de la vrification de l'laboration des systmes. Dans la NIP, il est dit que :

les vrifications avant la mise en oeuvre doivent tre effectues pour les principaux systmes en cours d'laboration dans les ministres et organismes; de plus, elles doivent se reflter dans les politiques et les plans de vrification interne des ministres et organismes; enfin, la possibilit d'un manque d'objectivit de la part du vrificateur peut tre minimise par l'tablissement d'un mandat appropri et d'une stratgie de mission adquate .

Cet expos tient donc compte de l'importance revtue par le contrle de la gestion sur les systmes en cours d'laboration, grce au processus de vrification.

Objet du guide

L'objet de ce guide est de permettre un vrificateur interne principal de procder une vrification des systmes en cours d'laboration. Ce genre de vrification se dfinit ainsi :

Examen et valuation, diffrentes tapes du cycle d'laboration des systmes, d'un systme choisi ou d'une amlioration apporte sur une grande chelle une application existante. La vrification comporte un examen de la conformit des aspects spcifis du processus d'laboration des systmes, pour un ministre donn, ainsi qu'un examen des contrles qui sont intgrs au systme, pour assurer que les donnes traiter soient compltes et exactes, en respectant les normes de scurit, d'autorisation et de vrification qui s'y appliquent.

Tout vrificateur devrait savoir que, dans le cadre d'une vrification de la technologie de l'information, les points valuer, outre les systmes en cours d'laboration eux-mmes, sont le centre d'informatique, les activits postrieures la mise en oeuvre, le fonctionnement du systme, le dictionnaire de donnes, l'informatique individuelle, la scurit des donnes et leur gestion, l'acquisition et la gestion de la technologie de l'information, ainsi que la possibilit de nombreux autres genres d'activits de vrification ayant souvent des rpercussions sur les questions qui sont du ressort d'une vrification des systmes en cours d'laboration. Ces points ne sont pas des objectifs, mais des questions examiner.

Les objectifs d'une vrification de ce genre sont noncs comme suit dans la NIP 1984-03 :

  1. La vrification du processus de gestion des projets et d'laboration des systmes.
  2. Les produits sont fonction du cadre de contrle, qui est conu paralllement au systme en cours d'laboration, ou qui en constitue une partie intgrante.

Organisation

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

Le chapitre 2 donne une description et un modle du cycle d'laboration des systmes, ainsi que des rles et des responsabilits des principaux intervenants.

Le chapitre 3 indique les objectifs et les critres d'une vrification des systmes en cours d'laboration, en se rapportant au contrle, l'conomie, l'efficience et l'efficacit oprationnelle pour chacune des tapes du processus. Ce chapitre traite tout d'abord des cinq principales activits de la vrification et de la faon dont ces activits se rattachent chacune des sept tapes du cycle d'laboration des systmes. Chacune des parties qui suivent dans le chapitre trois traite des objectifs de projet, d'intgrit des donnes et de contrle de la gestion des systmes pour chaque tape du cycle.

L'appendice A renferme un tableau des personnes interviewer pour chaque critre dtaill, et les appendices B H, les critres dtaills pour chaque tape du CES, du lancement aux activits postrieures la mise en place.

Pour terminer, l'appendice I prsente une bibliographie, et l'appendice J, une liste des politiques et normes pertinentes du Conseil du Trsor.

La valeur du processus d'laboration des systmes

Comme l'indique la Notice d'interprtation de la politique 1984-03 portant sur la vrification avant la mise en oeuvre :

les systmes ainsi mis en oeuvre ne rpondent pas toujours, loin de l, aux besoins des utilisateurs; les cadres de contrle des systmes, en particulier des systmes informatiss, ne sont souvent pas suffisamment labors; et les rcents programmes de rduction, (...) ont fait ressortir le besoin d'accrotre la productivit et l'efficacit de tous les processus. Le processus d'laboration des systmes fait donc l'objet d'un intrt tout particulier en raison des effets nfastes et fort coteux pouvant dcouler d'une analyse et d'une mise en oeuvre inadquates.

Lorsque l'on prend en considration l'investissement que reprsente l'laboration des systmes et le degr de dpendance des ministres vis--vis des systmes pour la gestion et la prestation de leurs programmes, on peroit clairement tout l'avantage que procurent la gestion des avertissements opportuns signalant toute dfaillance dans l'laboration des systmes. C'est pourquoi l'existence d'un cycle officiel d'laboration des systmes pour un ministre donn assure la prsence de normes essentielles qui permettent d'tablir un contrle de la gestion sur des projets particuliers ou sur des amliorations importantes qui ont t apportes.

Rapports sur les progrs de la vrification de l'laboration des systmes

La vrification d'un systme en cours d'laboration doit avoir lieu paralllement l'analyse du systme, et non pas aprs sa mise en oeuvre. Par ailleurs, si le concepteur du projet est rapidement inform des constatations de la vrification, il pourra plus facilement apporter les correctifs qui s'imposent. Il est de toute vidence que, plus la vrification est effectue tt dans le cycle d'laboration, plus les solutions apportes aux faiblesses dans l'analyse ou la gestion de projet sont efficaces. C'est pour cette raison que des mthodes dtailles ont t fournies au dbut du chapitre 3, la rubrique Aspects particuliers en matire de rapport . (Voir la figure 1)

Aspects particuliers

La vrification des systmes en cours d'laboration se diffrencie des vrifications portant sur le fonctionnement du systme et les activits postrieures la mise en place par le fait qu'elle permet de revoir l'laboration du mme systme jusqu' sept fois. Ainsi, une grande partie du travail accompli dans les tapes initiales du processus d'laboration devient un point de dpart pour la vrification des tapes plus tardives de l'laboration. Le chapitre 3 a t rdig la lumire de cette caractristique.

Le vrificateur doit dterminer si les activits du projet permettent de communiquer efficacement les incidences du projet sur les ressources humaines et si des mesures sont prvues pour traiter de ces incidences. Cet aspect particulier est tudi de faon plus dtaille au dbut du chapitre 3 et des objectifs de contrle ont t intgrs au cycle de contrle des activits lies au projet (A).

Le vrificateur doit galement dterminer, au tout dbut du processus d'laboration, si le projet tient compte de la planification stratgique du ministre et s'il est directement li aux objectifs de la haute direction. Les objectifs de contrle des activits lies au projet (A) (chapitre 3) ont t prvus cette fin.

Le vrificateur devrait songer recommander la technique de vrification et de corroboration fonde sur l'valuation du risque si les chargs du projet ne l'utilisent pas dj. Le chapitre 3 renferme plus de prcisions ce sujet.

On peut s'interroger sur l'objectivit du vrificateur dans son travail portant sur le fonctionnement du systme une date ultrieure, du fait qu'il participe au renforcement des contrles, tout au dbut. Ce point est trait de faon dtaille plus loin dans le rapport, mais on peut dj affirmer que l'affectation de vrificateurs diffrents la vrification portant sur le fonctionnement du systme devrait rgler le problme (voir le renvoi la NIP 1984-03 la page 1).

Figure 1: Le cot du changement

Le cot du changement

 




L'Environnement du processus d'laboration des systemes

Introduction

Ce chapitre prsente quelques dfinitions et descriptions fondamentales des facteurs internes et externes affectant le processus d'laboration des systmes dans le gouvernement. Son objectif est d'offrir une dfinition uniforme des termes utiliss dans la description des systmes, ainsi que de spcifier les facteurs considrs comme importants par les vrificateurs dans l'examen d'un systme.

Le chapitre est agenc comme suit :

  • dfinitions
  • facteurs importants :
    • infrastructure de gestion du ministre
    • politiques et normes du cycle d'laboration des systmes (CES)
    • processus de planification et d'acquisition
    • processus technologiques
    • politiques des organismes centraux
    • exigences en matire de services communs
    • scurit et protection des renseignements personnels

Dfinitions

a) Cycle d'laboration des systmes (CES)

Il s'agit l d'une approche structure qui divise un projet de systmes d'information en tapes distinctes qui sont suivies par des points de dcision et des approbations cls. Ceci permet une valuation ordonne du problme rsoudre, un processus ordonn d'analyse et d'laboration, et une mise en oeuvre ordonne de la solution. Une tape finale permet une rtroaction de la gestion et le contrle de celle-ci sur toute l'valuation postrieure la mise en oeuvre.

b) Mthodologie d'laboration des systmes

Il s'agit l de l'adaptation du CES un ministre donn, qui peut tre un ensemble interne de procdures, de formules et de processus pour chaque tape habituelle du CES, ou bien encore un ensemble commercial de logiciels, de procdures, de formules et de processus jugs plus efficaces par le ministre.

c) Projet d'laboration des systmes

Il s'agit l d'activits ncessaires pour rpondre aux exigences de la mthodologie particulire d'laboration des systmes qui est suivie, afin d'atteindre un ensemble d'objectifs ou de rsoudre certains problmes. Ces activits sont menes par une quipe travaillant sous la direction d'un gestionnaire de projet, qui devrait excuter toutes les activits CES normales de gestion pour la ralisation du projet.

L'environnement de l'laboration de projets

On a assist, au cours des annes 1980, une acclration des changements dans la complexit de l'environnement informatique. Non seulement la complexit des activits se rapportant l'laboration des systmes s'est-elle accentue, mais aussi l'ventail des fonctions intgres l'analyse et l'laboration des systmes. Ces changements dans la complexit et l'ventail des fonctions ont t en outre multiplis par une tendance de l' utilisateur final crer des systmes.

Nous continuerons voir augmenter l'utilisation des langages de quatrime gnration (L4G), la cration de prototypes, les mises en oeuvre pilotes et les instruments des logiciels d'tude des systmes assiste par ordinateur. Dans chaque cas, la vrification interne devra rajuster son approche, mais les principes fondamentaux exposs dans le prsent guide demeureront. Les modifications futures du guide traiteront directement de ces progrs rcents lis la mthodologie d'laboration des systmes.

Ces tendances ne feront qu'augmenter l'avenir.

Les vrificateurs 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 systmes. La figure 1.1 ci-aprs et les descriptions qui suivent illustrent ces facteurs.

Figure 1.1 : Cycle d'laboration des systmes

Cycle d'laboration des systmes

Descriptions des facteurs gnraux

Infrastructure de gestion du ministre

Le premier domaine prendre en considration est l'organisation gnrale du ministre et son infrastructure pour l'laboration des systmes. On s'intressera particulirement aux rles et responsabilits de l'organisme (ou des organismes) charg de la gestion de l'information, aux comits directeurs consultatifs ou se rapportant aux utilisateurs, ainsi qu'aux principaux comits de gestion du ministre.

Le vrificateur doit s'assurer du degr de coordination entre ces organismes et vrifier leurs ralisations antrieures. Ces renseignements permettront d'avoir un certain nombre d' indices quant aux questions ou secteurs d'enqute pouvant se prsenter et de connatre l'tendue de la participation antrieure de l'utilisateur, ainsi que de vrifier jusqu' quel point les gestionnaires ont su laborer des systmes efficaces dans le cadre des contraintes de temps et de cot.

Politiques et normes du CES

Un deuxime facteur important qui influence l'laboration des systmes est l'ensemble des politiques et normes du CES du ministre. Cet ensemble constitue en effet la base de l'laboration des systmes; sa raison d'tre est de souligner la dfinition des exigences avant le dbut de l'tape de conception, ce qui permet de rduire au minimum les modifications coteuses qui pourraient s'imposer plus tard dans le cycle d'laboration.

Le vrificateur interne doit, par consquent, examiner les politiques et les normes du ministre afin de s'assurer, de faon continue et pendant toute la participation au CES, que le projet d'laboration satisfait bien aux exigences du ministre.

Processus de planification et d'acquisition

Le plan de gestion de l'information (qui dcoule du plan des systmes et des techniques d'information (PSTI)) et le budget des immobilisations sont la troisime source principale d'information pour le vrificateur. Ces deux documents de planification sont prpars en tant qu'lments du plan oprationnel pluriannuel (POP) du ministre.

Bien que le nom et le contenu du processus exig par le SCT (l'ancien PSTI) aient chang depuis la premire dition du prsent guide, le principe que le vrificateur doit tout connatre de la planification stratgique, tactique et oprationnelle du ministre, 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 activits en cours et pour les nouvelles initiatives, ainsi que de l'affectation des ressources ncessaires la ralisation des stratgies, des politiques et des programmes relatifs l'informatique. Le PSTI tient galement compte du budget des immobilisations prvu pour les nouvelles acquisitions en informatique.

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

Le vrificateur interne doit examiner le PSTI et le budget des immobilisations afin d'tablir le lien qui convient entre ces documents de planification et le systme particulier qui est en cours d'laboration. En outre, il est important que le vrificateur s'assure que la planification tablie pour le projet d'laboration des systmes est relie au processus d'acquisition en informatique du ministre et est coordonne avec celui-ci.

Tendances de la technologie dans la fonction publique

L'ensemble des tendances de la technologie ayant une rpercussion sur la gestion de l'information dans la fonction publique constitue le premier facteur externe influencer fortement la faon dont le vrificateur peroit l'laboration des systmes. L' Aperu de la politique de gestion de l'information - Orientation stratgique en matire de gestion de la technologie de l'information dans le gouvernement fdral , publi par le Conseil du trsor en 1987 signale que :

La gestion des systmes d'information en fonction d'une approche se fondant sur les cycles d'laboration connatra une importance plus grande dans le gouvernement, compte tenu, dans un cadre de responsabilit accrue pour les ministres, des investissements oprs dans les systmes, des avantages reus et de la ncessit de planifier le remplacement des systmes.

Cet aperu prsente galement une valuation intressante de la situation actuelle et il convient de noter que chacun des principes noncs s'applique la vrification des systmes en cours d'laboration :

Les politiques actuelles sur l'informatique et les tlcommunications s'appuient sur des principes toujours valables :

  • les ressources sont utilises pour appuyer les programmes du gouvernement et ne constituent pas une fin en elles-mmes;
  • c'est le secteur priv qui rpond aux besoins du gouvernement, sauf lorsqu'il s'agit de l'intrt public ou qu'il est plus conomique de fournir les services de faon interne;
  • les ministres laboreront des plans annuels contenant de l'information sur les projets, l'quipement et le personnel, et ces plans dcouleront de plans plus long terme;
  • des efforts seront faits pour cerner les possibilits de partage de plans d'information, de l'information elle-mme et des comptences qui s'y rapportent;
  • les ministres tabliront leurs propres politiques internes;
  • l'approbation des projets d'laboration des systmes se fera par tapes;
  • la politique sur les micro-ordinateurs permettra de prendre galement en ligne de compte l'incidence sur les personnes et la ncessit d'une formation.

L'aperu continue en esquissant les rajustements qu'il faut oprer dans la porte de l'laboration des systmes et qui sont rendus ncessaires par la complexit accrue de l'environnement :

Il faut cependant des rajustements 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 dveloppements rcents, 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 cohrence des donnes l'chelle des ministres et du gouvernement dans un environnement o une puissance informatique plus grande est donne aux utilisateurs.

La lecture complte de l'aperu rvle, en rsum, que le domaine de l'laboration des systmes a t largi, et continuera l'tre. Voici les facteurs contribuant ce phnomne :

  • l'importance de la qualit et de la cohsion des donnes,
  • la capacit de traitement la disposition de l'utilisation,
  • la complexit et l'interactivit des systmes,
  • l'existence, le cas chant, de meilleurs instruments d'laboration, tels que la cration de prototypes, les langages de la quatrime gnration, les logiciels d'tude des systmes assiste par ordinateur et les logiciels de bases de donnes interactives (avec des dictionnaires de donnes actifs),
  • une augmentation, et non une rduction, des fonds investir pour le remplacement des systmes,
  • les questions critiques de ressources humaines en informatique,
  • l'inclusion ou l'intgration des tlcommunications.

Politiques et procdures des organismes centraux

Il existe deux organismes ayant une incidence sur la faon dont les systmes sont labors dans la fonction publique : la Direction de la politique administrative du Secrtariat du Conseil du Trsor (SCT) et la direction de l'Information et des systmes de gestion financire du Bureau du Contrleur gnral (BCG). La lgislation a prvu pour ces organismes un rle directeur dans la gestion et le contrle de la technologie de l'information. Dans ce rle, ils ont cr un fonds de politiques administratives, de directives et de lignes directrices connexes qui constituent une stratgie d'orientation et un cadre global que les ministres 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'accs l'information, les services communs, la micrographie, l'informatique, les tlcommunications et les micro-ordinateurs.

Cette Direction examine galement les plans de gestion de l'information (PGI) soumis par les ministres et organismes et prpare un examen annuel de la technologie et des systmes d'information utiliss par le gouvernement fdral. Le paragraphe 1.A.1.2 du chapitre 3 recommande que le vrificateur dtermine si le projet est bien intgr aux plans du ministre.

La Direction de l'information et des systmes de gestion financire (DISGF) encourage l'laboration de pratiques et de contrles de gestion solides au sein du gouvernement et surveille leur mise en oeuvre. Pour aider les employs chargs de mettre en place les systmes financiers, la Direction a fait publier des principes directeurs, des critres et des politiques portant sur l'laboration des systmes financiers; elle continue d'en laborer. L'appendice J (points 13 18) renvoie ces aides en matire d'laboration des systmes financiers. Il est trs important que les vrificateurs se tiennent au courant de ces critres et normes, au fur et mesure qu'ils sont publis, car ils feront partie de l'examen des contrles que le vrificateur effectuera au moment de l'laboration des systmes financiers.

La Direction est galement responsable du rle du BCG dans la stratgie en matire de gestion financire qui commence apparatre. La rfrence 19 de l'appendice J dcrit cette entreprise commune du BCG et de ASC. A ce stade, il suffit de dire que le vrificateur doit connatre la stratgie et savoir comment elle s'applique aux stratgies ministrielles relatives aux systmes financiers en voie d'laboration.

Les vrificateurs devraient galement tre au courant des ngociations de leur ministre dans le cadre du rgime d'accroissement des pouvoirs et des responsabilits ministriels (APRM) ainsi que des rpercussions de ces ngociations sur les systmes financiers en voie d'laboration. Le Bureau du contrleur gnral est le point de rfrence pour toutes les questions relatives aux exigences en matire de rapport de l'APRM.

Exigences en matire de services communs

La nature et la porte des services communs sont dcrites au chapitre 303 du Manuel de la politique administrative du Conseil du Trsor, ainsi que dans une srie de directives. Les services communs forment un lment important dans les oprations informatiques et leur gestion. Le chapitre 303 prcise 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 dpens et d'assurer l'observation plus uniforme de dcisions de politique socio-conomique et un respect plus pouss des exigences en matire de prudence et de probit . Le fait que les services communs s'tendent tout le gouvernement leur donne les caractristiques 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 systmes dans le gouvernement.

Le vrificateur doit donc dterminer si la gestion a considr l'incidence des exigences en matire de services communs (ainsi les services de salaires et pensions, les services d'achat, les services assurs par ASC, TPC, Communications, la BNC (Archives) et les autres services assurs par diffrents ministres) dans sa stratgies de planification.

Scurit et protection des renseignements personnels

La question de la scurit et de la protection des renseignements personnels au sein de l'environnement de la technologie de l'information a reu beaucoup d'attention depuis quelque temps, en particulier de la part de la Direction de la politique administrative du Secrtariat du Conseil du Trsor. Le Conseil a publi les documents suivants : Politique du gouvernement du Canada sur la scurit (rvise en septembre 1987), Scurit au gouvernement du Canada - Normes provisoires de scurit : 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 scurit. On se rapportera l'appendice J pour une liste de documents complmentaires.

Bien que certains des documents de rfrence qui suivent ne soient plus jour, ils peuvent renfermer des renseignements utiles. Le vrificateur doit examiner tout particulirement le Manuel de la politique administrative de d'autres publications, particulirement :

  • la Politique et les normes en matire de scurit du gouvernement du Canada (en vigueur);
  • l'bauche du Guide de la vrification de la scurit du BCG (en vigueur);
  • les normes provisoires sur la technologie de l'information (IIIe partie des Normes provisoires de scurit);
  • les mesures en cas d'urgence, GES/NE1-14 - 4.1.2.7;
  • les plans en cas de dsastre, 4.1.2.7.3;
  • la scurit des logiciels, 4.6;
  • l'assurance de la conception, de l'laboration et de la qualit, 4.6.2.

La scurit et la protection des renseignements personnels doivent idalement tre envisages par le vrificateur chaque tape du processus d'laboration des systmes, bien que toutes les exigences pertinentes la scurit et la protection des renseignements personnels doivent tre prises en ligne de compte ds le dbut du projet, en dterminant alors la personne qui assume les responsabilits de coordonnateur de la scurit en informatique et d'agent de la scurit pour le ministre. On doit galement dterminer au dbut de la vrification que l'on peut effectivement disposer des rapports pertinents tablis par l'quipe d'valuation et d'inspection de la scurit de la GRC.

 




Dtail du Processus d'laboration des systemes

Introduction

Ce chapitre dcrit le cycle d'laboration des systmes, ainsi que les rles jous dans ce cycle, de faon suffisamment dtaille pour permettre aux vrificateurs de procder une vrification de l'laboration, n'importe quelle tape du cycle d'laboration (CES) telle qu'intgre par un ministre son propre processus d'laboration des systmes (PES). Cela signifie que le vrificateur devrait tre en mesure d'valuer les progrs du projet, de comparer les ralisations tangibles celles juges normales par le prsent guide pour l'tape d'laboration l'tude. Ainsi, il devrait pouvoir situer le projet par rapport la norme. Le vrificateur pourra alors choisir, parmi les objectifs de vrification donns ce stade du CES normal, les objectifs qui s'appliquent au projet donn.

Le cycle d'laboration des systmes

La politique sur la Gestion des technologies de l'information diffuse en juin 1990 par le Conseil du Trsor remplace le chapitre 440.3 (Appendice J du prsent guide) du Manuel de la politique administrative du Conseil du Trsor (1978). Le chapitre 440 dfinissait le cycle d'laboration des systmes sur lequel se fondait le prsent guide. Mme si le Conseil du Trsor n'impose plus un CES en particulier, le prsent guide demeure valable pour ce qui est de dfinir la vrification d'un CES conforme aux pratiques acceptes d'laboration des systmes.

Le but d'un CES est de permettre aux concepteurs et aux utilisateurs de produire un systme contrl, conomique, efficient et efficace. Les tapes du processus d'laboration qui suivent ont t suggres par le Conseil du Trsor (MPA, 1978, Ch. 440) :

  • Lancement d'un projet
  • tude de faisabilit
  • Conception gnrale
  • Conception dtaille
  • Mise en oeuvre
  • Mise en place
  • Activits postrieures la mise en place

Mme si le CES conventionnel consiste en un cycle sept tapes, les CES particuliers de ministres 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 progrs en tablissant des liens avec la norme en matire de ralisation des sept tapes (voir la figure 3). Par consquent, comme il a t mentionn prcdemment, les objectifs et les critres de vrification prsents au chapitre 3 peuvent tre choisis pour la vrification d'un systme donn parmi les objectifs chronologiques du prsent guide qui s'appliquent la phase de vrification en question ou des phases antrieures.

De mme, une cole de pense veut actuellement que, une poque de micro-ordinateurs, de cration de prototypes ou de langages de la quatrime gnration, les organismes ne puissent se permettre les contraintes d'une mthodologie officielle s'appliquant au cycle d'laboration. Nanmoins, il incombe aux vrificateurs d'assurer l'existence de points valables pour le contrle 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 squence logique du CES conventionnel, sont essentiels.

Cration de prototypes

Avant que l'on procde 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 rcente.

La cration de prototypes appliqus est dfinie dans le prsent guide comme un modle visuel dynamique qui constitue un instrument de communication pour les utilisateurs ou les responsables de l'laboration des systmes, d'une efficacit suprieure celle de la simple prose ou des modles visuels statiques lorsqu'il s'agit de dcrire la fonctionnalit. Il s'agit d'une approche qui doit simuler le systme final et cette technique vient s'ajouter une mthodologie de gestion, qu'elle ne remplace pas. S'il a t clairement dcid d'adopter cette technique, la cration de prototypes doit tre utilise lors des tapes de faisabilit et de conception gnrale afin de dterminer les exigences fonctionnelles et les exigences en matire de donnes, en permettant la participation des utilisateurs par une exprience pratique aussitt que possible dans le cycle. Le vrificateur doit, aux tapes de faisabilit et de conception gnrale, examiner la dcision de l'quipe de projets et le contrle s'appliquant la cration de prototypes, dans le cas o cette technique a t retenue.

Le vrificateur 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 consquent, ne jamais devenir oprationnel. L'essai pilote, pour sa part, est conu pour devenir oprationnel.

Le vrificateur doit veiller ce que l'quipe comprenne bien la diffrence entre le prototype et l'essai pilote ou ce que des dcisions officielles aient t prises par les dtenteurs du pouvoir d'approbation pour que le prototype puisse passer l'tape de conception gnrale (ou une tape quivalente).

Gestion des donnes

Le vrificateur doit tre conscient du fait que les ministres ont tendance grer leurs donnes de faon formelle. Il doit galement tre conscient des rpercussions sur l'laboration des systmes que peuvent entraner, dans leur environnement, l'administration des donnes et l'administration des bases de donnes. Il pourra consulter comme rfrence le Rapport sur la stratgie 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-aprs illustre un exemple de mthodologie d'laboration, sous forme d'un graphique de cheminement, pour un environnement qui fait appel la gestion des donnes et des techniques de conception structures. Il ne s'agit pas de la mthode propose pour le CES conventionnel, mais la plupart des termes et des produits des tapes sont semblables ceux utiliss pour le CES conventionnel. En comparant les produits des tapes normalises aux produits du systme en cours d'laboration qui fait l'objet de la vrification, le vrificateur sera en mesure de choisir, dans le prsent guide, les objectifs quivalents de l'tape normalise. Il disposera donc d'une srie d'objectifs, qu'il pourra augmenter selon la nature du systme donn, qui lui permettront d'assurer une vrification optimale pendant l'laboration, quels que soient le CES particulier et les caractristiques particulires du systme.

La Figure 3 (ci-dessous, aprs la figure 2) prsente les produits attendus pour chacune des tapes du CES conventionnel.

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

Exemple de cycle d'laboration des systemes non conventionnel

Note 1 : Le dictionnaire de donnes actif permet l'ordinateur un plus grand contrle des mta-donnes (donnes sur les donnes dans le systme) que le dictionnaire passif.

Figure 3 : CES conventionnel - Produits attendus par tape

tape Activit Produit
Lancement
  • Demandes de filtrage
  • Dtails des documents
  • Planification et approbation
  • Rapport de lancement
  • Dfinition des problmes
  • Approche
  • Rles/Plan du projet
Faisabilit
  • Recueil des donnes
  • Analyse des donnes
  • laboration de solutions de rechange
  • valuation du design conceptuel
  • Rdaction du rapport
  • Rapport de faisabilit
  • Besoins de l'utilisateur
  • valuation des systmes de rechange
  • Design conceptuel
  • Concept
  • Plan du projet
  • Recommandations
Conception gnrale
  • Recueil des donnes
  • Analyse
  • Esquisse du systme
  • Esquisse des contrles
  • Assurance qualitative, objectif performance / secondaire
  • Objectifs en matire de scurit
  • Validation des besoins de l'utilisateur
  • Planification et approbation
  • Rapport de conception gnrale
  • Cots/Avantages rviss
  • Spcifications fonctionnelles
  • Contrles
  • Exigences techniques rvises
  • Plan du projet rvis
  • Plan de conception dtaille
Conception dtaille
  • Conception des sous-systmes
  • Cration des sous-systmes
  • Conception des aides l'utilisateur
  • Conception des tests pour le systme
  • Conception de la conversion
  • Prparation du rapport
  • Planification et approbation
  • Rapport de conception dtaille
  • Cots/Avantages rviss
  • Exigences techniques rvises
  • Description du systme
  • Procdures pour l'utilisateur
  • Plan du projet rvis
  • Plans de mise en oeuvre et de mise en place
  • Plan de formation
Elaboration
  • Codage des logiciels
  • Tests du systme et des units
  • Production d'aides l'utilisateur
  • Planification et approbation
  • Rapport de mise en oeuvre
  • Programmes documents
  • Manuel de prodcure pour l'utilisateur
  • Manuels de formation et d'oprations
Mise en oeuvre
  • Installation des quipements
  • Tests pour les accepter
  • Formation et conversion
  • Opration et approbation
  • Achvement du projet
  • Avis d'approbation
Activits postrieures la mise en place
  • Rajustements apports au systme
  • Recueil des donnes sur  les activits postrieures
  • la mise en place
  • Rapport d'valuation

Description des tapes

1. tape de lancement d'un projet

Les activits excutes cette tape doivent tre la dfinition formelle du mandat du projet et l'tablissement de ses paramtres de contrle.

Les procdures l'gard d'un projet comportent un examen prliminaire du systme existant (s'il en existe un) afin d'valuer la ncessit de changements et la nature de ces derniers. On doit donc dfinir le problme . Une solution potentielle doit tre conceptualise pour servir de rfrence pendant l'tape d'tude de faisabilit. La solution ne doit pas tre dcrite trop en dtail, cela pouvant nuire aux solutions de rechange examines lors de l'tude de faisabilit.

A ce moment, on doit dterminer toutes les contraintes externes et internes (cot, temps, lgislation, lignes directrices du ministre, besoins de l'utilisateur, etc.), et valuer leur incidence sur le problme et sur la solution qui aura t retenue. On doit galement valuer lors de cette tape la question de la scurit, y compris les exigences concernant la relance informatique la suite d'un sinistre, ainsi que les points se rapportant la protection des renseignements personnels.

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

2. tape de faisabilit

A la fin de cette tape, on devrait avoir dtermin une solution convenant au problme ainsi qu'un plan prliminaire pour sa mise en oeuvre.

Les exigences de l'utilisateur, qui peuvent tre documentes ou tablies par la cration de prototypes, servent de fondement la solution retenue.

Il est de la plus grande importance d'tudier suffisamment d'autres approches possibles. Une analyse dtaille des diffrentes solutions de rechange, au niveau conceptuel, doit appuyer le choix officiel de la solution propose. Cette analyse doit comporter une analyse cots/avantages (ou des techniques semblables) et envisager les contrles financiers et oprationnels, de mme que la compatibilit organisationnelle. Comme l'tape de lancement du projet, on doit s'assurer que les valuations sont objectives et compltes, et qu'elles ne favorisent pas une solution particulire.

On doit prciser les exigences en matire de ressources pour le reste du projet et procder une valuation du temps et du cot ncessaires, pour leur approbation par la gestion. L'nonc des exigences rparties entre chacune des tapes du projet, servira contrler son laboration.

Les lments qui prcdent doivent tre documents dans un rapport de faisabilit.

3. tape de conception gnrale

Le travail accompli lors de cette tape transposera la solution conceptuelle propose, qui aura t dtermine pendant l'tude de faisabilit, en une solution pratique se prtant la conception dtaille et la mise en oeuvre.

Ce travail exigera :

  • la prparation d'une esquisse du systme, y compris les graphiques de cheminement, les critres de performance du systme, ainsi que la spcification, la dfinition et le formatage prliminaire de toutes les entres et sorties, et de tous les fichiers utiliss ou produits par le systme; (cela demandera des contacts intensifs avec les utilisateurs.)
  • une vue d'ensemble du cadre de contrle interne et des procdures de fonctionnement pour que l'on puisse s'assurer qu'elles rpondent aux objectifs du systme en cours d'laboration, (le systme propos doit satisfaire toutes les exigences de l'utilisateur.)
  • la slection d'installations et de descriptions de tches pour les fournisseurs ou les faonniers;
  • une esquisse de toutes les spcifications fonctionnelles permettant de s'assurer que la conception gnrale rpond tous les objectifs du systme dtermins.
  • les cots rviss, les valuations de temps et les autres critres se rapportant aux tapes venir, pour leur approbation par la gestion.

La documentation de l'information recueillie lors de cette tape sera normalement incluse dans un rapport sur la conception gnrale. Il est possible que certains ministres prfrent prparer deux rapports, dont un pour mettre en vidence la conception du systme de gestion lui- mme. Dans tous les cas, ces lments doivent tre clairement documents.

4. tape de conception dtaille

Des procdures dtailles et des spcifications informatiques sont produites partir des spcifications fonctionnelles nonces lors de l'tape de conception gnrale. Tous les contrles, procdures, cheminements du travail, documents des entres et des sorties, logiques de traitement, dispositions des fichiers et des bases de donnes, ainsi que les lments de donnes seront compltement mis au point.

L'approbation de cette tape de conception par la gestion et les utilisateurs est d'une importance capitale. Par consquent, le produit final de cette tape, le rapport de conception dtaille, doit contenir, outre les spcifications des programmes et les cheminements du travail dtaills, etc., une description non technique de tout le systme, qui comprendra :

  • une description du systme, des objectifs, des entres et des sorties;
  • un graphique de cheminement, indiquant le design conceptuel.

Les cadres de gestion concerns doivent examiner les spcifications dtailles, ainsi que les exigences techniques.

On doit galement produire, lors de cette tape, des plans documents d'essai des systmes, ainsi que des plans de mise en oeuvre et de conversion. En outre, on produira un plan portant sur la faon dont seront coordonnes les activits des tapes de mise en oeuvre et de mise en place, ce qui comportera la prparation de manuels d'instruction (pour les utilisateurs et les oprateurs). On devra galement dfinir les procdures de formation, de scurit, de sauvegarde et de conversion.

5. tape de mise en oeuvre

Les activits de cette tape aboutiront la cration de tous les programmes, formules, manuels et documents de formation pour l'informatique ncessaires un systme oprationnel.

Une logique de programmation dtaille sera conue et des logiciels d'application seront cods.

Les manuels se rapportant l'utilisation, aux oprations et la formation seront mis au point et devront, le cas chant, couvrir les points suivants :

  • la saisie des donnes
  • la validation des donnes
  • les pistes de vrification et les mcanismes de contrle du systme
  • la vrification des rapports d'analyse
  • les consignes d'exploitation de l'ordinateur
  • les procdures de sauvegarde et de rexcution
  • les procdures de scurit

Tous les aspects du systme, y compris la logique des programmes et les procdures oprationnelles, doivent tre compltement mis l'essai. De mme, toutes les procdures ncessaires la mise en place du systme doivent tre dfinies et faire l'objet d'un calendrier.

6. tape de mise en place

Lors de cette tape, le systme est rendu oprationnel. Le travail comportera la conversion des fichiers existants (s'il y en a) ou la cration de la base d'information initiale, la formation convenable du personnel participant au systme (utilisateur et informatique), ainsi que l'tablissement de procdures de contrle ou de procdures oprationnelles, par une gradation d'oprations pilotes ou parallles. Toute la documentation provenant des tapes antrieures doit tre finalise. Les procdures de conversion et de mise en place doivent faire l'objet d'un examen et d'essais. Le gestionnaire de projets doit alors prsenter un avis formel d'achvement du projet pour qu'il soit approuv.

7. tape d'activits postrieures la mise en place

Le travail effectu lors de cette tape consiste en un examen de la performance du projet et de la performance du systme par rapport la documentation de projet originale sur les cots/avantages du systme, ainsi qu'avec le cot du projet et les calendriers.

Un certain dlai est normalement allou entre la mise en place et la vrification postrieure celle-ci. L'quipe de vrification peut alors tre galement change pour maximiser l'objectivit, ce qui rduira par contre l'efficacit de la vrification.

Ainsi, les examens du projet peu de temps aprs la mise en place d'un systme sont importants afin d'valuer le succs du processus d'laboration des systmes et de relever toute diffrence entre la conception des contrles et leur fonctionnement.

Conclusion de la description des tapes

Comme on l'a indiqu prcdemment, il doit exister des normes adquates dans les ministres, qui doivent tre suivies pour chaque tape de CES afin d'assurer un contrle cohrent et complet de la gestion sur la mise en oeuvre. Toutefois, il peut tre appropri que le ministre ait dfini et approuv un ensemble distinct d'activits de CES se fondant sur le genre de projet qui est en cours (c.--d. l'laboration des systmes majeurs ou mineurs). Il est normal de documenter l'approbation que la gestion a apporte toute dviation vis--vis des normes du ministre.

Dans de nombreux cas d'laboration par l'utilisateur final de micro ou de mini-ordinateurs, un examen de l'importance revtue par les donnes ou par l'information pour l'organisation peut justifier une partie ou la totalit des points de CES se rapportant aux contrles.

En valuant si l'laboration ou la modification d'un systme est assez minime pour justifier le regroupement ou l'limination de quelques-unes des tapes de CES, le vrificateur doit garder prsent l'esprit le fait que certains changements relativement mineurs peuvent revtir une importance trs grande du point de vue des contrles.

Rles

Les descriptions typiques qui suivent illustrent comment chaque tape du modle de CES fournit la gestion une assurance de contrle, d'conomie, d'efficacit et d'efficience. Il s'agit de descriptions lmentaires; les vrificateurs peuvent nanmoins s'attendre rencontrer de telles personnes ou de telles activits dans un environnement contrl. Ces rles, ou leur quivalent, et d'autres rles figurent l'appendice A comme des personnes qui poser les questions lies aux objectifs et critres proposs pour chaque tape de vrification.

Gestion

La gestion doit jouer un rle d'examen pour assurer que le systme labor rponde aux objectifs de l'organisme. La gestion assigne des priorits aux projets, aux budgets et aux chanciers. C'est la gestion qui tablit les politiques et les normes du ministre pour l'laboration des systmes, puis qui exerce son contrle sur le processus d'laboration en s'assurant qu'un CES soit en place et fonctionne d'aprs son analyse.

La gestion a une responsabilit majeure, soit de dcider l'importance du risque pouvant tre tolr dans un projet.

Il est possible que la gestion ait besoin de l'aide technique de tiers pour l'aider assurer ses responsabilits.

Comit directeur ou personnes dotes du pouvoir d'approbation

Chaque organisme gouvernemental nomme en gnral une personne dote du pouvoir d'approbation pour chaque tape du processus d'laboration. Ensemble, ces personnes reprsentent le pouvoir d'approbation. Certains ministres ont un comit directeur de l'informatique au niveau du SM charg d'examiner tous les rapports de vrification des systmes. Ce comit dispose parfois de l'approbation finale. Le point cl dans la vrification 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 suprieurs.

Concepteur/analyste

Le concepteur/analyste reprend les exigences de l'utilisateur pour laborer un systme rpondant 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 systme est fonctionnelle. Le concepteur/analyste a galement la responsabilit d'un contrle gnral du systme sur les donnes qui dpassent ou intgrent les contrles de programme individuels, et doit choisir la solution d'analyse technique optimale convenant au systme. Le vrificateur doit s'assurer que le rle de contrle de l'analyste n'est pas compromis par le gestionnaire de projet ou toute autre personne.

Programmeur

Le programmeur est responsable de la cration d'un programme efficace et efficient partir d'une spcification du programme reue de l'analyste ou du reprsentant fonctionnel. Le programme peut tre un dialogue ou un module du systme global et les contrles figurant dans la spcification doivent permettre de s'assurer que les donnes conservent leur intgrit tout le long du processus de traitement. Le programmeur voit mettre en place les contrles sur les donnes dans le processus de mise en forme des entres, dans le traitement informatique interne des programmes, ainsi que dans les sorties affiches, communiques ou imprimes.

Utilisateurs

C'est l'utilisateur qui doit clairement dfinir et appuyer les objectifs, les exigences et les besoins auxquels le systme doit satisfaire dans les tapes initiales d'laboration. Il est galement de sa responsabilit d'tablir les exigences en matire de contrle technique non informatique et de s'assurer que le systme qui en rsulte ralise le contrle demand. L'utilisateur peut avoir besoin de l'aide technique de tiers pour s'assurer que le contrle voulu soit en place.

Processus de scurit dans le ministre

Le chapitre 440 du Manuel de la politique administrative du Conseil du Trsor indique les responsabilits, en matire de scurit du ministre, de la GRC, du ministre des Approvisionnements et Services, du ministre des Communications, du ministre des Travaux publics et de l'quipe d'inspection et d'valuation de la scurit en informatique. En outre, ce chapitre indique brivement le rle de l'agent de scurit du ministre et du Comit consultatif de la scurit, dans le cadre des deux activits de coordination et d'administration de la scurit. Chaque ministre doit fournir, directement ou en consultant l'quipe d'inspection et d'valuation de la scurit en informatique de la GRC, des conseils, des normes et une valuation des contrles physiques (et non logiques) ncessaires dans ce ministre pour les donnes, l'information et les actifs matriels. La dlgation de signature, manant de l'autorit d'approbation, doit tre en vidence chaque tape du projet d'laboration des systmes.

Le point 12 de l'appendice J contient d'autres rfrences concernant la scurit.

Gestionnaire ou administrateur des donnes dans le ministre

La gestion des donnes et de l'information acquiert dans de nombreux ministres une importance renouvele du fait qu'elle constitue un lment d'actif critique. On peut dcrire l'administration des donnes comme regroupant les fonctions de planification, d'administration et de contrle des donnes se rapportant aux activits d'un organisme. Le personnel provenant du secteur de la gestion ou de l'administration des donnes doit tre considr comme membre cl de l'quipe de projet.

Administrateur de la base de donnes du ministre

L'administration de la base de donnes regroupe la planification, les dcisions, le contrle et toute autre fonction menant directement aux bases de donnes oprationnelles, 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 donnes, le vrificateur doit s'assurer que ce dernier fait partie de l'quipe de projet.

Vrificateurs internes

Les vrificateurs internes doivent examiner et valuer les contrles de gestion utiliss dans l'laboration de nouveaux systmes d'application ou d'amliorations importantes. Ils chercheront des preuves d'une participation relle de l'utilisateur dans l'analyse et l'acceptation du systme; ils chercheront galement des preuves d'une attention relle porte l'analyse dtaille du systme et des procdures pour apporter un contrle gnral et un contrle dans l'application.

Le degr exact de participation des vrificateurs l'laboration des systmes est dtermin par le risque encouru par l'organisme pour l'activit d'laboration. Ce risque se compose des lments de cots d'laboration, de cot oprationnel et de la dpendance de l'organisme vis--vis de l'information traite. L'activit d'analyse et d'laboration des systmes reprsente aujourd'hui une part croissante du temps et des dpenses des organismes, et ces derniers sont plus dpendants que jamais vis--vis du fonctionnement continu de leurs systmes informatiques. Le vrificateur doit, tout comme il tablit l'importance relative de leurs constatations, donner les raisons pour lesquelles il a prfr certains critres d'autres pendant l'tape de planification de la vrification. Pour ce faire, il dtermine quel serait le risque pour le ministre si un contrle de gestion particulier tait mal exerc. Dans certains cas, cette approche permet de traiter de vastes projets d'laboration des systmes avec trs peu de vrificateurs.

Il est possible que le vrificateur dcouvre des documents trs complexes que l'on juge ncessaires pour expliquer la relation existant, dans le rle de l'laboration des systmes, entre les gestionnaires de produits, les concepteurs des systmes de communication, les administrateurs de bases de donnes, les dtenteurs de donnes, les utilisateurs, les clients et de nombreux autres termes qui ont fait leur apparition pour traiter du monde plus complexe de l'informatique dcrit au chapitre 1.

Sauf en ce qui concerne l'laboration des exigences l'gard des systmes l'intention du groupe de vrification, en tant qu'utilisateur du systme, le vrificateur ne doit jamais tre directement tenu responsable d'une activit de projet. Il se situe en dehors de l'quipe du projet mme s'il peut lui offrir des conseils sur le contrle, que ce soit par des lettres ou par des rapports. Il doit, dans toutes les tapes d'laboration qui ont t dcrites, vrifier que tous les points et les concepts touchant les rles ou la prsentation de rapports soient bien documents.

Dans toutes leurs activits d'examen d'laboration des systmes, les vrificateurs doivent s'assurer que leur indpendance n'est pas compromise, en vue d'examens ultrieurs des systmes en cours. On obtient normalement ce rsultat en affectant des vrificateurs diffrents aprs que le systme a t mis en place, lequel dpend aussi de la faon dont le vrificateur d'laboration des systmes observe les faiblesses de contrle et recommande des amliorations leur gard. Le vrificateur doit toujours s'opposer participer l'analyse mme du systme.

 




Excution de la vrification : la vrification applique au processus d'laboration des systemes

Introduction

Ce chapitre traite du processus de vrification 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 prsent guide pour viter la confusion avec l'expression phase utilise en vrification.

Porte et objet

La vrification des systmes 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 systme en cours d'laboration fournit des pistes de vrification et des contrles suffisants pour assurer l'intgrit des donnes traites et stockes; et donner un avis sur les contrles exercs pour la gestion du fonctionnement du systme. Ces objectifs sont clairement identifis dans le chapitre 3, l'intention des vrificateurs, par un A (Contrle des activits lies au projet), un B (Contrle de la validit des donnes), ou un C (Contrle des oprations du systme) comme deuxime indicateur dans les parties relatives aux objectifs, aux critres et aux critres dtaills.

Pour atteindre le premier objectif, le vrificateur assiste aux runions du comit de projet et du comit directeur, examine la documentation des contrles du projet et effectue des entrevues. L'accent est mis sur l'tablissement, avec le concours de l'entit vrifie, de normes de contrle du projet (p. ex., un processus formel d'laboration des systmes) et la dtermination du degr d'observation de ces normes. Pour excuter cette activit, le vrificateur doit garder prsentes l'esprit les exigences de l'ancien chapitre 440 du Manuel de la politique administrative du Conseil du Trsor, le contenu de toutes les circulaires, politiques et normes donnes l'appendice J, ainsi que la documentation couverte par le Guide de vrification du processus de gestion du BCG.

Pour le deuxime objectif, le vrificateur se limite examiner la documentation sur le systme, comme les spcifications fonctionnelles, pour se former une opinion sur les contrles. Cette opinion sera fonde sur la mesure dans laquelle le systme de technologie de l'information rpond aux objectifs gnraux en matire de contrle. Une liste de ces objectifs devrait tre fournie l'entit vrifie. Il en va de mme pour le troisime objectif, les contrles oprationnels du systme. Le vrificateur devrait fournir l'entit vrifie une liste des contrles standard, en ce qui a trait aux questions oprationnelles, comme le dlai de rponse, l'utilisation de l'unit centrale, et la disponibilit de l'espace d'accs direct, qu'il a utilises comme critre d'valuation.

Phases de la vrification

La vrification d'un systme en cours d'laboration demande l'excution de certaines procdures chaque tape du CES. Bien que cette mthode semble segmenter le processus en vrifications spares et distinctes, ce n'est pas le cas; la vrification d'une tape ou d'un groupe d'tapes doit tenir compte de toutes les vrifications antrieures (ou de l'absence de vrification) effectues dans le processus continu d'laboration d'un systme.

Pour effectuer la vrification des systmes en cours d'laboration, les activits suivantes, communes toutes les vrifications faites selon les normes du Conseil du Trsor, doivent figurer chacune des phases de la vrification :

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

Les activits qui prcdent se tiendront pour la plupart l'occasion d'une vrification de systme en cours d'laboration, avec une certaine variation dans leur application.

Aspects particuliers de la phase de planification

Toutes les phases de la vrification d'un CES doivent tre planifies et incluses dans la planification initiale de la vrification d'un systme en cours d'laboration. A mesure que la vrification du CES avance, le plan de vrification doit prciser quelle tape fait l'objet de la vrification et mettre jour les plans visant les autres tapes.

Phase d'examen et d'valuation

L'activit d'examen et d'valuation sera poursuivie chacune des phases de vrification pour vrifier si le systme suit le processus du CES. Cependant, puisqu'on commence documenter et programmer les contrles au cours de l'tape de faisabilit, l'examen et l'valuation de l'intgrit des donnes et des contrles du systme ne peuvent tre effectus qu'aux phases de l'tude de faisabilit, d'analyse gnrale, d'analyse dtaille, de mise en oeuvre, de mise en place et de vrification des activits postrieures la mise en place.

Phase de corroboration

Tout au long du processus d'laboration, le vrificateur vrifiera la conformit de celui-ci avec le CES (voir l'approche dtaille en 4.A.10.1). Le vrificateur ne testera pas les contrles mais examinera plutt leur conformit avec les normes de test pour le CES. L o les tests n'ont pas t suffisants, le vrificateur doit immdiatement en aviser les gestionnaires du projet. Les tests sont une fonction se rapportant l'utilisateur et l'quipe de projet. La participation directe du vrificateur l'excution des tests peut compromettre son objectivit, mais il peut dcider d'effectuer certains tests nouveau, afin d'appuyer les conclusions du contrle.

Aspects particuliers de synchronisation des rapports

Une caractristique importante des vrifications des systmes en cours d'laboration est que l'on y vite un rattrapage coteux des contrles, ce qui ne peut toutefois tre ralis que l o la communication entre le vrificateur et le service vrifi permet de prendre rapidement des mesures pour corriger les points relevs par la vrification. Pour bien servir les intrts de la haute direction, les rapports de vrification doivent suivre le processus d'laboration du systme. Toutefois, ds qu'il peut les tayer, le vrificateur doit galement communiquer ses constatations une personne au niveau de gestionnaire de projet. Pour garantir l'objectivit de la vrification et tenir la haute direction au courant des activits de la vrification des systmes en cours d'laboration, la prsentation de rapports sommaires de vrification devrait concider avec les tapes du projet et les points de contrle. Par exemple, le processus peut prvoir les tapes ci- dessous :

  • lancement d'un projet
  • tude de faisabilit
  • conception gnrale
  • conception dtaille
  • mise en oeuvre
  • mise en place
  • activits postrieures la mise en place.

Dans ce cas, les sorties de vrification comporteraient un protocole de plan de vrification devant tre prsent tous les niveaux de gestion pendant la vrification de l'tape de lancement du projet ainsi que des rapports sommaires de vrification, selon le processus ordinaire de prsentation de rapports de vrification, aprs chacune des tapes de vrification suivantes.

Par ailleurs, les activits de vrification des systmes en cours d'laboration doivent tre prvues de manire aider les hauts fonctionnaires lorsque les prsentations au Conseil du Trsor doivent tre approuves par le ministre. Habituellement, le vrificateur met un avis sur le caractre raisonnable des renseignements sur les cots/avantages que renferme la prsentation, mais il peut galement entamer une vrification d'autres renseignements contenus dans la prsentation.

Note

Les tudes de CES prsentes ci-dessus s'appliqueraient surtout aux nouveaux systmes majeurs en cours d'laboration ou des changements importants apports aux systmes existants. Dans l'laboration des systmes plus petits, ou lorsque des changements mineurs sont apports des systmes existants, on peut regrouper les tapes de CES ou en abandonner quelques-unes. Dans ce dernier cas, l'quipe de projet doit faire particulirement attention ne pas lser le systme. Par exemple, si l'on ne prend pas suffisamment les solutions de rechange en considration dans l'tape de faisabilit, il peut en rsulter la slection d'une solution de rechange inapproprie. Le facteur cots, lorsqu'il est dcid d'abandonner une tape, doit tre considr en regard du risque encouru.

La cration de prototypes a t dcrite au chapitre 2. Les questions et les contrles 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 amliorations apportes aux systmes dj en place, peuvent tre considrs comme assez importants pour tre envisags comme des projets de CES complets en eux-mmes. Les points de vrification seraient alors identiques ceux dcrits ci-dessous.

On doit dfinir des normes d'laboration pour chaque tape du CES et s'y tenir pour assurer une cohrence dans l'laboration de tous les projets des ministres. Nanmoins, un ministre donn pourrait dfinir un ensemble spar de normes fondes sur le genre de projet qui est entrepris (laboration de systme majeur ou mineur), ce qui contribuera assurer que des normes minimales sont appliques dans les activits d'laboration des systmes mineurs.

Finalement, lorsqu'il tablit si un systme est assez petit pour justifier le regroupement ou l'limination de certaines tapes du CES d'une vrification, le vrificateur doit garder l'esprit que certains changements relativement mineurs peuvent tre trs importants du point de vue des contrles. L'importance d'une modification apporte un systme doit tre value avec soin si l'on pense s'carter des normes.

Objectifs de contrle pour chacune des tapes

Voici maintenant les objectifs de contrle, les critres et les critres dtaills se rapportant chaque tape d'laboration de projets pour le contrle des activits lies au projet (A), le contrle de la validit des donnes (B) et le contrle d'oprations du systme (C).

Les premiers contrles sont naturellement examins chaque tape d'laboration afin que l'on puisse se faire une opinion sur l'efficience, l'efficacit et l'conomie de l'excution du projet. Heureusement les contrles de l'entre, de l'intgrit des donnes et de la gestion du systme peuvent n'tre examins que lors des tapes d'tude de faisabilit, d'analyse gnrale, d'analyse dtaille et de mise en oeuvre, afin de permettre des donnes de vrification opportunes (voir figure 4). L'tape d'tude de faisabilit est incluse, pour le cas o les exigences en matire de contrle peuvent se rapporter au choix d'une approche d'analyse.

Il est noter que si certains critres de contrle des projets sont rpts d'une tape de vrification une autre, le vrificateur doit traiter chaque phase de vrification du guide comme une phase distincte. Cela signifie qu'il doit tenir compte des objectifs de toutes les phases de vrification antrieures la phase o il est rendu lorsqu'il dtermine quels objectifs appliquer la phase de vrification.

Finalement, les sections du chapitre sont identifies par des chiffres et des lettres qui permettent au lecteur de savoir quelle phase et quel objectif de vrification il est rendu dans le texte. Le diagramme qui suit permet de bien comprendre le systme d'identification :

Figure 4 : Activits de vrification pour chaque tape d'laboration

tape Projet Donnes Systeme
Lancement  OUI NON NON
tude de faisabilit OUI OUI OUI
Conception gnrale OUI OUI OUI
Conception dtaill OUI OUI OUI
Mise en oeuvre OUI OUI** OUI*
Mise en place OUI NON NON
Activits postrieures la mise en place OUI OUI** OUI**

OUI signifie qu'une activit de vrification doit avoir lieu ce stade.

NON signifie qu'aucune activit de vrification ne doit avoir lieu ce stade.

* Les contrles du systme font partie de l'examen des essais effectus lors de cette phase. (Voir le critre 5.A.3.2 l'appendice F).

** Comprend la rexcution de certains tests de contrle.

Les renseignements de vrification que renferme le reste du chapitre et les appendices connexes sont identifis au moyen d'un numro de classification Dewey quatre zones (voir la figure 5). Grce ce numro, le lecteur pourra savoir o il est rendu dans le texte.

Figure 5 : Exemple du Systme de classification Dewey

1.A.1.1

tapes du ces : 

  • Lancement
  • Faisabilit
  • Conception gnrale
  • Conception dtaille
  • Mise en oeuvre
  • Mise en place
  • Activites postrieures la mis en place

1.A.1.1

Objectifs :

A = Contrle des activits lies au projet

B = Contrle de la validit des donnes

C = Contrle d'oprations du systme

1.A.1.1

Critres

1.A.1.1

Procdures de vrification

1. tape de lancement du projet

Il est essentiel que la participation du vrificateur soit communique officiellement au comit directeur des systmes du ministre, ce qui s'effectuera par l'entremise d'un protocole formel stipulant la ncessit de la prsence du vrificateur aux runions de l'quipe de projet et du comit directeur.

Aprs que le vrificateur aura termin la phase de planification de la vrification de l'tape de lancement, un protocole formel pour le plan de vrification sera publi, indiquant la participation des vrificateurs pour le reste du projet.

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

Questions concernant le contrle des activits lies au projet (A)

L'expression utilisateur ou direction des utilisateurs utilise dans les objectifs, les critres ou les critres dtaills signifie la collectivit des utilisateurs , habituellement reprsente par un ou plusieurs membres de l'quipe de projet. La collectivit des utilisateurs peut reprsenter une ou plusieurs entits distinctes au sein du ministre. Le vrificateur doit veiller la juste reprsentation de la collectivit au sein de l'quipe.

On doit justifier clairement l'entreprise d'un nouveau processus d'laboration, gnralement par une analyse conomique; cependant, dans certains cas, on peut le faire en valuant le besoin de services amliors ou supplmentaires, ou d'autres proccupations 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 prliminaire des conditions qui serviront mesurer l'efficacit du nouveau systme garantissent que la dcision de lancer le projet a t prise aprs considration de l'information ncessaire.

Le contrle, l'organisation, les responsabilits et les autorits s'appliquant au projet doivent tre tablis clairement.

Risques principaux

On doit intgrer au plan de vrification des activits de vrification visant traiter des risques principaux suivants, qui pourraient empcher que les exigences de l'utilisateur ou du projet soient satisfaites :

  • le caractre vague des problmes relevs et de la porte du projet;
  • l'acceptation d'un plan de projet qui ne contribue pas aux objectifs du ministre ou de l'organisme ou sa planification stratgique;
  • la faiblesse de la gestion du projet, tant en ce qui concerne les ressources humaines que financires (tablissement d'un budget);
  • l'insuffisance de l'valuation du risque li au projet;
  • l'insuffisance de la documentation des questions touchant la scurit et la protection des renseignements personnels, y compris le niveau d'autorisation de scurit et de fiabilit, exig et rel, pour les membres de l'quipe.

Objectif

1.A Dterminer si le projet a t lanc officiellement et si des contrles adquats sont exercs.

Critres

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

1.A.2 Les utilisateurs et les gestionnaires responsables du traitement des donnes jugent le projet ncessaire.

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 ralisation du projet ainsi que les tches et les responsabilits.

1.A.5 Le rapport sur le lancement du projet renferme un plan de travail qui indique, notamment, les dlais fixs.

1.A.6 L'organisation du projet, les tapes de ralisation et le plan de travail ont t approuvs officiellement par un gestionnaire de niveau appropri.

Note 1 : Cet objectif et les critres qui s'y rapportent correspondent aux programmes de vrification de l'appendice B qui portent le mme nom.

Note 2 : Comme il est indiqu la figure 4, il n'existe aucun objectif relatif au contrle de la validit des donnes (B) ou au contrle des oprations du systme (C) pour l'tape de lancement (1) puisqu'il n'est pas ncessaire de documenter les contrles cette tape (voir la figure 3).

2. tape de l'tude de faisabilit

Lors de l'tape de lancement du projet, le problme a t dcrit. L'objectif de cette tape est donc d'tudier les exigences des utilisateurs en gnral afin de dterminer la solution conceptuelle qui convient, en termes de compatibilit organisationnelle, de justification conomique et d'adaptation technique. On prparera des spcifications dtailles lors de l'tape suivante en s'appuyant sur ces exigences, gnralement regroupes dans le DOCUMENT DES EXIGENCES DE L'UTILISATEUR.

Questions concernant le contrle des activits lies au projet (A)

Le vrificateur doit s'assurer que les exigences de l'utilisateur ont t releves et documentes en dtail. L'quipe du projet doit runir avec grand soin l'information contenue dans le document sur les exigences des utilisateurs grce ceux d'entre eux qui, ne connaissant pas le potentiel d'un nouveau systme, ne limitent pas pour autant leur dfinition des exigences.

Toutes les solutions de rechange pratiques doivent avoir t releves et analyses. Les faits et les valuations cots/avantages utiliss 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 ncessaires doivent tre compltes et raisonnables. Du fait que ces valuations serviront au contrle budgtaire et au contrle du projet, il est impratif que toute l'information soit convenablement dtaille.

Risques principaux

On doit intgrer au plan de vrification des activits lies aux risques principaux suivants :

  • l'information fournie la gestion dans des buts d'valuation, d'approbation et de planification peut tre incomplte ou inexacte, voire les deux;
  • la solution de rechange optimale n'a pas t retenue;
  • la planification, le contrle et l'administration sont inadquats;
  • de nombreux utilisateurs prouvent de la difficult vrifier leurs besoins prcdemment exposs lorsqu'ils ont faire face un document volumineux. Le vrificateur doit dterminer si l'quipe de projet a utilis une mthode valable pour assurer la participation active de l'utilisateur en vrifiant les exigences de celui-ci (ainsi, la cration de prototypes dcrite);
  • il est possible que la gestion suprieure traite cette tape d'approbation de faon rapide tant donn qu'elle requiert peu de ressources. Dans ce cas, il pourrait en rsulter que les phases subsquentes soient excutes sans que cette phase importante ait t finalise.

Objectif

2.A Dterminer si une tude de faisabilit (y compris un plan de projet global) a t ralise dans le but de trouver la solution idale un problme donn du point de vue organisationnel, conomique et technique.

Critres

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 donnes estiment que la dfinition des besoins est prcise et complte.

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 donnes estiment que l'analyse des solutions de rechange est fonde sur des donnes prcises et compltes, y compris les contraintes et les risques, et approuvent les recommandations formules.

2.A.5 Le rapport sur l'analyse cots/avantages (ou un document semblable) renferme une estimation des ressources humaines et financires requises.

2.A.6 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que l'analyse des cots/avantages est fonde sur des donnes prcises et compltes, et approuvent la solution de rechange recommande.

2.A.7 Le gestionnaire responsable du projet s'est inspir de la solution de rechange recommande dans l'analyse des cots-avantages pour prparer un sommaire des aptitudes personnelles :

  • aptitudes requises, administratives et techniques
  • niveau de comptence requis
  • nombre d'employs requis
  • niveau d'autorisation ncessaire

2.A.8 Les comptes rendus des runions 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 donnes estiment que l'tude de faisabilit (ou un document semblable) est fonde sur des donnes prcises et compltes, et l'approuvent ou jugent que les problmes ont t rgls leur satisfaction.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice B qui portent le mme nom.

Intgration du contrle de la validit des donnes (B) et d'oprations du systme (C)

Dans cette tape d'laboration, l'utilisateur, qui est en fin de compte responsable de l'intgrit des donnes, doit faire connatre ses exigences se rapportant au contrle de la validit des donnes (B). Ces exigences doivent tre prises en considration au moment de mener l'tude de faisabilit et l'analyse cots/avantages afin d'assurer leur inclusion dans le systme. Les exigences se rapportant au traitement et au contrle de la scurit ou de la protection des renseignements personnels doivent tre incluses dans le document des exigences de l'utilisateur, ou le prototype quivalent.

Les contrles d'oprations du systme (C) sont les contrles ncessaires pour s'assurer que le systme continue fonctionner de faon efficiente et efficace aprs sa mise en place. Ces contrles diffrent des contrles sur les donnes et l'information et ont des objectifs diffrents. Les contrles de la gestion, portant sur le fonctionnement du systme, doivent correspondre la dfinition des exigences pour le systme lui-mme et l'analyse cots/avantages.

Risques principaux

On doit intgrer au plan de vrification des activits de vrification lies aux risques principaux suivants :

  • toute valuation inadquate par la gestion suprieure des utilisateurs de la documentation sur les exigences en matire de contrle des donnes, ainsi que la solution de rechange retenue au moment de l'approbation de cette phase; et
  • le manque de prcision de la part de l'utilisateur ou de l'oprateur en matire de contrle de gestion du systme.

Objectif

2.B Dterminer si les donnes traites et emmagasines par le systme sont compltes, prcises et dment autorises, et si des mesures de scurit, de protection des renseignements personnels et d'accs l'information sont prvues.

Critres

2.B.1 La fiche de contrle (ou un document de ce genre) indique les mesures de contrle prvues.

2.B.2 Le reprsentant des utilisateurs a pris bonne note du niveau de scurit, de protection des renseignements personnels et d'accs l'information des donnes emmagasines par le systme; et sait dans quelle mesure le systme et les donnes sont sensibles en cas de perte, de destruction, d'accs non autoris et de modifications.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice C qui portent le mme nom.

Objectif

2.C S'assurer que les contrles en place assurent le fonctionnement efficient, efficace et conomique du systme.

Critre

2.C.1 La configuration de base (ou un document de ce genre) fait tat des exigences en matire de contrle de la gestion du systme.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice C qui portent le mme nom.

3. tape de conception gnrale

A cette tape, on prpare des spcifications dtailles des exigences de l'utilisateur partir de la solution de rechange au systme conu qui a t approuve l'tape prcdente. Les spcifications qui en rsultent sont exprimes dans les termes de ceux qui remplissent les fonctions de gestion vises et sont libres de tout point d'analyse technique. Les spcifications fonctionnelles seront traduites en une analyse de systme l'tape suivante.

Les questions de scurit doivent demeurer une proccupation de la vrification cette tape, ainsi qu'on l'a not la fin du chapitre 2.

Questions concernant le contrle des activits lies au projet (A)

On doit avoir surveill la performance des projets pendant l'tape de conception gnrale, par rapport aux plans et budgets tablis lors de l'tape de faisabilit, et justifier les carts auprs des autorits de projets.

Le systme, dans son analyse, doit rpondre aux exigences des utilisateurs. Les points concernant les contrles (financier et oprationnel) doivent avoir t traits. Dans certains cas, le mandat de la vrification peut demander l'valuation de ces contrles d'application.

On doit s'tre occup des lments manuels et automatiss du nouveau systme.

La documentation doit traiter suffisamment en dtail de tous les lments du systme pour permettre une analyse dtaille du systme.

Risques principaux

Dans le plan de vrification, on doit prendre en considration les risques principaux suivants :

  • le relev et la dfinition incomplets ou inexacts des facteurs cls;
  • le manque de correspondance entre les besoins dfinis et rels;
  • l'valuation insuffisante des cots/avantages du systme; et
  • la non obtention de l'approbation ou de l'autorisation aux points de contrle dsigns.

Objectif

3.A S'assurer que la conception gnrale du systme est fonde sur les constatations de l'tude de faisabilit, qu'elle produit une description fonctionnelle du manuel d'instructions et des procds informatiques, et qu'elle donne lieu la conception d'un systme permettant d'obtenir un engagement quant la poursuite de l'laboration.

Critres

3.A.1 Le rapport sur la configuration du systme (ou un document de ce genre) fait tat des caractristiques du systme.

3.A.2 Les utilisateurs au niveau appropri et les gestionnaires responsables du traitement des donnes estiment que la configuration du systme est prcise et complte.

3.A.3 Le dictionnaire ou rpertoire des donnes a t mis jour en fonction de la configuration du systme.

3.A.4 Toutes les ressources humaines ncessaires ont t affectes la ralisation du projet.

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

3.A.6 Le rapport sur l'analyse gnrale (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 donnes estiment que le rapport sur l'analyse gnrale est complet et prcis, et l'approuvent.

3.A.8 Une analyse de l'incidence sur les ressources humaines est planifie.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice D qui portent le mme nom.

Intgration au systme du contrle de la validit des donnes (B) et d'oprations du systme (C)

L'quipe de projet, compose de reprsentants des utilisateurs et de l'informatique, doit choisir les techniques permettant de satisfaire aux exigences en matire de contrle labores lors de l'tape de faisabilit. Cette slection n'est limite que par l'imagination des membres de l'quipe. Le travail du vrificateur ce point consiste valuer le contrle, et non les capacits techniques des utilisateurs.

Risques principaux

Les activits de vrification intgres au plan de vrification doivent tenir compte des risques principaux qui suivent :

  • l'inexactitude des donnes d'un projet doit tre prise en compte dans la planification de la vrification afin de dterminer l'tendue, la nature et la synchronisation des procdures de vrification cette tape et toutes les tapes de CES subsquentes;
  • le manque de prcision, de la part de l'utilisateur, quant aux techniques permettant de satisfaire aux exigences en matire de contrle de gestion des systmes, du fait qu' il est trop tt pour le savoir .

Objectif

3.B Dterminer si les donnes traites et emmagasines par le systme sont compltes, prcises et dment autorises.

Critres

3.B.1 Afin de satisfaire aux exigences nonces dans la liste des contrles la configuration du systme (ou un document semblable) nonce les mthodes de contrle du traitement des donnes.

3.B.2 Les utilisateurs au niveau appropri et les gestionnaires responsables du traitement des donnes estiment que les mthodes de contrle du traitement des donnes sont compltes et prcises.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice D qui portent le mme nom.

Objectif

3.C Dterminer si le systme fonctionnel est exploit de faon efficace et efficiente.

Critres

3.C.1 Afin de satisfaire aux exigences nonces dans la liste des contrles, la fiche de contrle de gestion (ou un document de ce genre) nonce les mthodes de contrle de la gestion du systme.

3.C.2 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que les mthodes de contrle de la gestion du systme sont compltes et prcises.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice D qui portent le mme nom.

4. tape de conception detaillee

Pendant l'tape d'analyse dtaille, on traduit les spcifications fonctionnelles prpares aux tapes prcdentes en une description du systme qui permettra de rpondre aux exigences fonctionnelles spcifies. L'analyse du systme sera alors mise en oeuvre dans des systmes informatiss et manuels lors de l'tape de mise en oeuvre.

Le principal objectif de cette tape est de traduire les spcifications d'analyse des utilisateurs en systmes, processus de bases de donnes qui fonctionneront dans le cadre des contraintes de matriel et de logiciels des systmes.

Points concernant le contrle des activits lies au projet (A)

On devrait avoir surveill la performance du projet l'tape d'analyse dtaille, par rapport aux plans et budgets tablis lors de l'tape de faisabilit (ou leur rvision subsquente), et justifi les carts auprs des autorits du projet.

Tous les lments du systme devront avoir t conus en dtail. Les lments manuels et informatiss, ainsi que les caractristiques de contrle du systme devront avoir t envisags.

Si le mandat de vrification comprend l'valuation des contrles d'application, un examen, dcrit dans le Guide de la vrification des contrles d'application peut se rvler ncessaire.

L'analyse dtaille est l'analyse complte et finale du systme oprationnel, c'est--dire qu'il ne doit y avoir aucun dfaut ou aucune incohrence technique apparent. Selon le mandat de vrification, le vrificateur peut examiner les preuves que cela a t tabli ou s'en assurer directement grce une rexcution de l'valuation.

Risques principaux

Les activits de vrification intgrer au plan de vrification couvrent les risques principaux suivants :

  • Les principes sous-jacents l'analyse de l'approche des tests peuvent s'avrer inappropris et mener, par consquent, des conclusions fausses.
  • Une information insuffisante sur les caractristiques du matriel et des logiciels, ainsi que sur les conditions des contrats peuvent empcher des choix optimaux.
  • L'valuation des cots et avantages du systme peut tre inexacte ou incomplte.
  • L'tape de mise en oeuvre peut avoir t amorce sans que la planification et les essais ncessaires aient t achevs.

Objectif

4.A Dterminer si une conception dtaille a t mise au point partir des caractristiques fonctionnelles tablies au moment de la conception gnrale.

Critres

4.A.1 Le rapport sur la conception dtaille (ou un document de ce genre) fait tat des caractristiques de la programmation.

4.A.2 Les utilisateurs au niveau appropri et les gestionnaires responsables du traitement des donnes estiment que les caractristiques sont prcises et compltes.

4.A.3 Le dictionnaire ou rpertoire des donnes a t mis jour en fonction du document sur les caractristiques de la conception dtaille.

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

4.A.5 Les utilisateurs au niveau appropri et les gestionnaires responsables du traitement des donnes estiment que le plan de mise l'essai est prcis 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 affectes la ralisation du projet.

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

4.A.9 Le rapport sur la conception dtaille (ou un document de ce genre) examine le projet par rapport au budget et au calendrier tablis dans le rapport sur la conception gnrale.

4.A.10 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la conception dtaille renferme des donnes prcises et compltes, et s'ils l'approuvent.

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

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice E qui portent le mme nom.

Intgration au systme des contrles de la validit des donnes (B) et d'oprations du systme (C)

A ce stade de la conception dtaille, les techniques de contrle de l'application releves lors de l'tape prcdente ont t transformes en contrles des entres, du traitement et des sorties.

A beaucoup d'gards, la vrification des contrles de la gestion des donnes et des systmes commence ressembler la vrification d'un systme en activit. La principale diffrence est que le vrificateur doit vrifier les tests de l'quipe de projet et ne devrait rexcuter les tests de contrle que de faon slective.

Les contrles d'entres porteront sur la transmission, l'acceptation, la conversion et la validation des donnes, ainsi que sur la correction des erreurs. Les contrles du traitement porteront sur la restriction l'accs et la vrification de l'intgrit des donnes entre les tapes du traitement et l'intrieur des bases de donnes. Ils minimiseront galement l'incidence des pannes des systmes sur les systmes en direct. Les contrles des sorties consistent en un rapprochement et un quilibrage gnraliss des fichiers des sorties et des rapports, et portent sur les mesures de scurit connexes.

Jusqu' un certain point, la nature des contrles d'application mis au point sera fonction de leur application un systme particulier. Par consquent, il n'est pas pratique d'essayer de prvoir l'inclusion des spcifications dtailles de l'analyse des systmes se rapportant chaque technique de contrle. L encore, l'appendice I contient des renvois des ouvrages traitant de la vrification des systmes en activit. En plus d'examiner les tests entreprendre par l'quipe de projet pour vrifier que ces tests couvrent bien les exigences en matire de contrle, le vrificateur doit commencer relever les contrles devant tre tests nouveau (A NOUVEAU et non pour la PREMIERE FOIS), aprs que l'on dispose des premiers programmes, c'est--dire probablement la fin de l'tape de mise en oeuvre ou au dbut de l'tape de mise en place.

Risques principaux

On doit intgrer au plan de vrification des activits de vrification qui traitent du risque principal suivant :

  • la non inclusion de toutes les exigences en matire de contrle dans le plan des tests.

Objectif

4.B Dterminer si les donnes traites et emmagasines par le systme sont compltes, prcises et dment autorises.

Critres

4.B.1 Dterminer si le plan de mise l'essai (ou un document de ce genre) fait tat des mthodes de contrle du traitement nonces dans le rapport sur le contrle du traitement.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice E qui portent le mme nom.

Objectif

4.C Dterminer si le systme est exploit de faon efficace et efficiente.

Critre

4.C.1 Dterminer si le plan de mise l'essai (ou un document de ce genre) fait tat des mthodes de contrle ncessaires pour respecter les exigences nonces dans le rapport sur le contrle de gestion du systme.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice E qui portent le mme nom.

5. tape de mise en oeuvre

Le systme en cours d'laboration est mis en oeuvre dans des systmes informatiss et manuels devant tre oprationnels lors de l'tape suivante, d'aprs les spcifications de l'analyse des systmes documentes dans les tapes prcdentes.

Des programmes informatiques et des procdures manuelles sont rdigs et tests. Des documents de formation et le calendrier de mise en place sont prpars.

Points concernant le contrle des activits lies au projet (A)

On doit avoir surveill la performance du projet pendant l'tape de mise en oeuvre, par rapport aux plans et aux budgets tablis lors de l'tape de faisabilit (ou leurs rvisions subsquentes), et justifi les carts auprs des autorits de projets.

Les tests des systmes et programmes doivent tre complets et entirement documents. Les problmes rencontrs doivent avoir t rgls. Le vrificateur peut choisir de rexcuter certains tests de faon slective, mais ne doit jamais tre peru comme tant responsable des tests.

Les manuels d'utilisations, les formats des entres et des sorties, la prsentation sur l'cran et toute autre forme d'interface avec l'utilisateur doivent tre conus pour optimiser leur efficacit.

Risques principaux

Les activits de vrification intgrer au plan de vrification couvrent les risques principaux suivants :

  • Il peut ne pas y avoir eu de prparation suffisante pour l'emplacement. Le vrificateur doit veiller ce que la mise en place des lignes de tlcommunications, la livraison du matriel et la prparation de l'emplacement n'aient pas t compromises du fait que la date de mise en place concide avec l'expiration des ressources budgtaires.
  • Des plans de formation peuvent ne pas avoir t labors et partags avec les utilisateurs de faon adquate.
  • Le personnel des systmes peut ne pas comprendre compltement les besoins des utilisateurs.
  • La documentation de l'analyse des systmes, programmes ou dialogues, et des manuels d'utilisation peut tre insuffisante.
  • Les tests peuvent tre insuffisants par suite des contraintes de temps ou d'autres contraintes s'appliquant aux ressources.

Objectif

5.A Dterminer si tous les formulaires, manuels, programmes et documents de formation appropris ont t prpars partir des spcifications dtailles de la conception.

Critres

5.A.1 Tous les manuels et autres documents requis ont t prpars avant l'installation du systme.

5.A.2 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que les manuels et les documents requis renferment des donnes compltes et prcises.

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

5.A.4 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la mise l'essai renferme des donnes prcises et compltes.

5.A.5 Toutes les ressources humaines ncessaires restent affectes la ralisation du projet.

5.A.6 Le calendrier des runions du comit directeur (ou un document de ce genre) indique la date de toutes les runions prvues, 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 dtaille.

5.A.8 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la mise en oeuvre renferme des donnes prcises et compltes, et s'ils approuvent ce rapport.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice F qui portent le mme nom.

Intgration au systme des contrles de la validit des donnes (B) et des oprations du systme (C)

Des contrles sont intgrs au nouveau systme, lors de cette tape, pour assurer l'intgrit des donnes et la gestion des systmes. Les efforts principaux du vrificateur portent surtout sur la vrification des tests, traite dans la partie qui prcde, mais il existe maintenant une possibilit de rexcution slective des tests pour les contrles cls.

L'appendice I prsente des documents de rfrence pour la dtermination des techniques appropries permettant de tester nouveau les contrles choisis, d'aprs la nature du systme et son environnement. Les systmes en direct temps rel, faisant appel des systmes de gestion des bases de donnes sous le contrle d'une gestion administrative des donnes spares, exigeront de nouveaux tests plus complexes que les systmes typiques entres par lots, ou fichier matre sur bande magntique. Le recours judicieux aux documents de rfrence permettra au vrificateur ayant une exprience suffisante en informatique d'excuter de nouveaux tests efficients et efficaces.

Risques principaux

On doit intgrer au plan de vrification des activits qui tiennent compte des risques principaux suivants :

  • Si le vrificateur se fie totalement une vrification des documents produits par l'quipe de projets pour les tests qu'elle a effectus, il pourrait en rsulter des jugements errons quant au caractre complet et exact de ces tests.
  • Il est possible que le vrificateur consacre une partie de ses efforts de nouveaux tests sur les contrles qui sont en cours de reprogrammation. On devra donc veiller dterminer le degr de stabilit du systme de tests avant de rexcuter des tests de contrle choisis.

Objectif

5.B Dterminer si les principaux contrles de transmission sont efficaces.

Critre

5.B.1 Exercer de nouveau certains contrles de la validit des donnes.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice F qui portent le mme nom.

Objectif

5.C Dterminer si les principaux contrles exercs sont efficaces.

Critre

5.C.1 Exercer de nouveau certains contrles de la validit des donnes.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice F qui portent le mme nom.

6. tape de mise en place

Lors de cette tape, le systme devient oprationnel. La formation commence et les fichiers sont convertis.

Le systme est mis en place d'aprs le plan labor lors de l'tape prcdente, ce qui peut exiger un processus chelonn, p. ex. par emplacement gographique, par composante organisationnelle ou en fonction des besoins. Dans le dernier cas, la fixation de critres serait ncessaire. Une signature d'acceptation est demande l'utilisateur.

Points concernant le contrle des activits lies au projet (A)

On doit avoir surveill la performance du projet pendant l'tape de mise en place, par rapport aux plans et budgets tablis lors de l'tape de faisabilit (ou leurs rvisions subsquentes) et justifi les carts auprs des autorits du projet.

La conversion des donnes doit tre exacte. Les tests du processus de conversion des donnes doivent tre bien documents. D'aprs la qualit et l'excution des tests excuts par l'organisme vrifi, le vrificateur peut dcider de rexcuter certains tests.

Risques principaux

On doit envisager, lors de cette tape de vrification, des activits portant sur les risques cls suivants :

  • Conversion des fichiers inexacte ou incomplte.
  • Formation du personnel insuffisante.
  • Mauvaise gestion du passage de l'ancien au nouveau systme.
  • Fonctionnement des systmes dfectueux, par suite d'une formation incomplte et (ou) d'une participation inefficace de l'utilisateur pendant les tests d'acceptation.
  • A mesure qu'approche la fin de l'anne financire ou de tout autre genre de contrainte de calendrier, de temps ou d'argent, la formation, les tests et le contrle des projets sont assujettis des tensions ngatives qui affectent les ractions de l'quipe de projets aux recommandations de vrification provenant des tapes antrieures.
  • Il est possible qu'il n'existe pas de plan d'urgence test la disposition des oprateurs du systme.

Objectif

6.A Dterminer si le systme et la conversion de fichiers (le cas chant) passent du stade de dveloppement au stade d'opration et d'entretien.

Critres

6.A.1 La prcision, l'intgralit et l'authenticit des fichiers crs par voie de conversion sont assures grce l'application des mthodes de contrle appropries.

6.A.2 La formation a t assure conformment au calendrier prpar cet effet.

6.A.3 L'installation a t effectue conformment au calendrier prpar 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 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur l'installation renferme des donnes prcises et compltes, et s'ils approuvent ce rapport.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice G qui portent le mme nom.

Note 2 : Comme il est indiqu la figure 4, il n'existe aucun objectif pour les contrles de la validit des donnes (B) et les contrles d'oprations du systme (C) l'tape de la mise en place (6).

7. tape des activits postrieures a la mise en place

Pendant cette tape, le systme sera en opration et sera soumis des changements systmiques contrls afin de fonctionner de faon satisfaisante et selon les besoins courants. On doit prparer un rapport sur le projet, trois six mois aprs la mise en place du systme, pour indiquer son degr de conformit avec les exigences fonctionnelles des utilisateurs et le degr de conformit aux cots/avantages prvus.

Questions concernant le contrle des activits lies au projet (A)

Les activits de vrification lors de cette tape comportent un examen du rapport de suivi et des documents de travail, par rapport toute la documentation des tapes prcdentes, afin d'assurer leur conformit avec le CES et d'attester le l'exactitude et l'intgrit des rsultats observs.

Risques principaux

On doit inclure dans le plan de vrification des activits portant sur les risques principaux suivants :

  • on peut ne pas disposer d'un nombre suffisant d'oprateurs qualifis, de documentation satisfaisante pour le systme et les utilisateurs ou de soutien appropri;
  • on peut ne pas disposer de soutien prenant la forme de conseils techniques par ligne directe , de techniciens de centre d'information, etc.;
  • on peut ne pas disposer de renseignements bien documents sur les cas d'insuffisance oprationnelle, qui permettraient la gestion d'en prvenir la rptition.

Objectif

7.A Dterminer si le systme est exploit conformment aux objectifs de conception et autres critres d'valuation, et si les cots/avantages prvus sont atteints.

Critres

7.A.1 L'installation a t suivie d'un examen et si les rsultats ont t communiqus aux membres de la haute direction.

Note 1 : Cet objectif et les critres qui s'y rattachent correspondent aux programmes de vrification de l'appendice G qui portent le mme nom.

Note 2 : Comme il est indiqu la figure 4, il n'existe aucun objectif pour les contrles de la validit des donnes (B) et les contrles d'oprations du systme (C) l'tape des activits postrieures la mise en place (7).

 




Annexe A : Grille des entrevues

Lgende

  • ABD = Administrateur de la base des donnes
  • C/A = Concepteur/analyste
  • GDM = Gestionnaire des donnes du ministre
  • Gest = Gestion
  • Prog = Programmeur
  • GP = Gestionnaire de projet
  • CD/PA = Comit directeur ou personne dote du pouvoir d'approbation
  • Scu = Agent de scurit du ministre
  • Util = Users Utilisateurs
tape de vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu 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 vrification GP Gest CD/PA C/A Prog Util Scu GDM ABD
7.A.1.1 X         X      
7.A.1.2 X         X      
7.A.1.3 X         X      
7.A.1.4 X         X      
7.A.1.5 X         X      






Annexe B : Programme de vrification de l'tape de lancement du projet

tape : 1. Lancement du projet

Objectif : 1.A Dterminer si le projet a t lanc officiellement et si des contrles adquats sont exercs.

Critre : 1.A.1. Dterminer si le rapport sur le lancement du projet (ou un document semblable) indique que le projet est ncessaire.

tape de vrification : 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 vrification : 1.A.1.2 Vrifier si ce document contient au moins les points suivants :

  • un nonc clair de la dfinition du projet prpar par le groupe client;
  • un lien clairement tabli entre le plan de gestion de l'information (PGI) et le plan oprationnel pluriannuel (POP) du ministre;
  • des assurances que les donnes et le systme ne sont pas dj prvus dans des systmes ou d'autres projets existants;
  • une valuation du systme en cours pour s'assurer que le systme propos est bien ncessaire;
  • un nonc des contraintes internes et externes, p.ex. des changements organisationnels et des changements lgislatifs ncessaires, des incidences sur les autres systmes;
  • les exigences particulires en matire de scurit;
  • une analyse cots/avantages prliminaire et l'analyse des risques pour les autres solutions viables;
  • une explication de la source du financement pour le projet, y compris un renvoi toute exigence particulire, telle que les prsentations au Conseil du Trsor.
Oui Non S/O Observations Renvois
         
Critre : 1.A.2. Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes jugent le projet ncessaire.

tape de vrification : 1.A.2.1 Le document de lancement a t examin un niveau de gestion suprieur d'au moins un chelon aux personnes qui seront tenues directement responsables et la ncessit d'excuter le projet a t reconnue.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.2.2 L'quipe de projet a pris des mesures pour reprer et consulter toutes les parties concernes.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.2.3 Le projet a t approuv sur le plan financier.

Oui Non S/O Observations Renvois
         
Critre : 1.A.3 Dterminer si le rapport sur le lancement du projet indique l'organisation du projet.
tape de vrification : 1.A.3.1 Dterminer, par examen du document de lancement du projet, les points suivants :
  • Les membres de l'quipe et les reprsentants ont t nomms incluant :
    • Le directeur (la directrice) du projet
    • Le gestionnaire du projet
    • Le directeur/gestionnaire utilisateur
    • Les reprsentants techniques
    • Reprsentant utilisateur fonctionnel
  • un comit directeur ou un pouvoir d'approbation ont t tablis
  • le cas chant, un fonctionnaire de la Direction des programmes du CT a t dsign et son rle dtermin
Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.2 Examiner les antcdents et les qualifications des membres du projet pour les affecter des tches particulires.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.3 La direction du ministre client a-t-elle affect au projet des employs de son ministre?

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.4 Les employs du ministre client et l'quipe de projet comprennent-ils de la mme faon la porte et les objectifs du projet?

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.5 Dterminer si le gestionnaire de projet, ou l'un des membres de l'quipe, a la responsabilit de s'assurer d'une compilation complte et exacte des cots du projet.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.6 Dterminer si le comit directeur ou les dtenteurs du pouvoir d'approbation reprsentent bien la gestion, que leur niveau est suprieur d'au moins un chelon celui du gestionnaire de projet, et qu'ils reprsentent galement toutes les parties intresses.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.3.7 Dterminer si l'on a tabli et vrifi le niveau, exig et rel, d'autorisation de scurit et de fiabilit s'appliquant aux membres de l'quipe.

Oui Non S/O Observations Renvois
         
Critre : 1.A.4 Dterminer si le rapport sur le lancement du projet indique les tapes de ralisation du projet.

tape de vrification : 1.A.4.2 Des variantes du processus ministriel approuv ont-elles t releves et les motifs de l'cart ont-ils t noncs?

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.4.3 Dterminer si la cration de prototypes (voir le dbut du chapitre 2) a t considre comme une technique d'laboration possible, en portant attention aux points suivants :

  • la prvention de l'abus de prototypes (voir au chapitre 2, page 16, la description sommaire d'un prototype);
  • le recours au prototype aux tapes appropries (c.--d. de l'tape de faisabilit celle de la conception gnrale);
  • la participation relle des utilisateurs l'laboration des prototypes (dterminer si le prototype tient bien compte des besoins des utilisateurs);
Oui Non S/O Observations Renvois
         
Critre : 1.A.5 Dterminer si le rapport sur le lancement du projet renferme un plan de travail qui indique, notamment, les dlais fixs.

tape de vrification : 1.A.5.1 Dterminer en se rfrant au document de lancement du projet si un plan de travail comportant un chancier et des exigences en matire de ressources a t prpar.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.5.2 Vrifier si le total des exigences en matire de ressources indiqu dans le plan de travail correspond aux rsultats de l'analyse cots/avantages prliminaire.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.5.3 Vrifier si l'chancier qui figure dans le plan de travail tient compte des exigences en matire de ressources indiques et de toutes les contraintes.

Oui Non S/O Observations Renvois
         

tape de vrification : 1.A.5.4 Vrifier si le plan de travail prvoit l'laboration d'un plan en matire de ressources humaines pour tous les employs qui seront touchs par le nouveau systme.

Oui Non S/O Observations Renvois
         
Critre : 1.A.6 Dterminer si l'organisation du projet, les tapes de ralisation et le plan de travail ont t approuvs officiellement par un gestionnaire de niveau appropri.

tape de vrification : 1.A.6.1 Le document de lancement a-t-il t examin par des niveaux de gestion suprieurs d'au moins un chelon aux personnes qui sigeront au comit directeur ou qui dtiennent 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 vrification : 1.A.6.2 Existe-t-il un plan pour que le gestionnaire de projet prsente des rapports priodiques la gestion et les rapports contiendront-t-ils les cots et les ralisations du projet, en comparaison des plans.

Oui Non S/O Observations Renvois
         





Annexe C : Programme de vrification de l'tape de l'tude de faisabilit

tape : 2. tude de faisabilit

Objectif : 2.A Dterminer si une tude de faisabilit (y compris un plan de projet global) a t ralise dans le but de trouver la solution idale un problme donn du point de vue organisationnel, conomique et technique.

Critre : 2.A.1 Dterminer si le rapport sur les besoins des utilisateurs (ou un document de ce genre) examine les besoins des utilisateurs.

tape de vrification : 2.A.1.1 Un document des exigences de l'utilisateur a-t-il t prpar et communiqu? Tient-il compte des besoins suivants de l'organisme pour l'accomplissement de sa mission :

  • description de la fonction actuelle;
  • lacunes de la fonction actuelle;
  • ressources affectes la fonction actuelle;
  • volume de travail produit avec la fonction actuelle, y compris le rendement en priode de pointe et la croissance prvue;
  • exigences en matire de contrle interne et de scurit;
  • justification des amliorations et des changements;
  • porte et objectifs du systme propos;
  • solutions autres que la satisfaction du besoin;
  • liens avec d'autres systmes;
  • liens avec les plans long terme et d'autres documents pour la gestion des ressources informatiques.

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

Oui Non S/O Observations Renvois
         
Critre : 2.A.2 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que la dfinition des besoins est prcise et complte.

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

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

tape de vrification : 2.A.2.2 L'quipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernes.

Oui Non S/O Observations Renvois
         
Critre : 2.A.3 Dterminer si l'tude de faisabilit (ou un document de ce genre) renferme une analyse des solutions de rechange.

tape de vrification : 2.A.3.1 Une tude de faisabilit technologique a-t-elle t prpare et documente?

  • Existe-t-il des normes organisationnelles relatives au contenu des tudes de faisabilit technologique et la faon de les excuter?
  • La technologie propose est-elle ralisable compte tenu du degr de perfectionnement sur le plan technique qui existe ou qui est disponible dans l'organisme.
Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.3.2 Vrifier si cette tude porte sur les points suivants :

  • besoins en matriel et disponibilit du matriel;
  • besoins en logiciels et disponibilit des logiciels;
  • besoins en matriel et en logiciels de communications et disponibilit du matriel et des logiciels;
  • contraintes de temps valables relatives aux besoins en information du ministre client et faon de les satisfaire;
  • faisabilit sur le plan oprationnel (c.--d., le nouveau projet s'intgre-t-il bien au matriel, aux logiciels et aux systmes de communications en place?);
Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.3.3 Vrifier si les ministres clients et les concepteurs s'entendent sur les aspects technologiques de la configuration du systme.

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.3.4 Dterminer si l'organisme est en mesure de grer les technologies connexes et de dcider si elles doivent tre achetes ou conues, exploites sur place ou l'extrieur et si leur maintenance doit se faire sur place ou l'extrieur.

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.3.5 confirmer auprs de sources indpendantes la fiabilit et la performance du matriel et des logiciels recommands.

Oui Non S/O Observations Renvois
         
Critre : 2.A.4 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que l'analyse des solutions de rechange est fonde sur des donnes prcises et compltes, et s'ils approuvent les recommandations formules.

tape de vrification : 2.A.4.1 L'tude de faisabilit a-t-elle t examine par le comit directeur ou les dtenteurs du pouvoir d'approbation?

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

tape de vrification : 2.A.4.2 L'quipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernes?

Oui Non S/O Observations Renvois
         
Critre : 2.A.5 Dterminer si le rapport sur l'analyse cots/avantages (ou un document semblable) renferme une estimation des ressources humaines et financires requises.

tape de vrification : 2.A.5.1 Un document des cots et des avantages a-t-il t prpar et communiqu? Tous les cots sont-ils dfinis comme cots de fonctionnement ou cots d'immobilisations?

Note : On doit galement se servir, ce point de la vrification, de l'information provenant des comits consultatifs sur la gestion de l'information (CCGI) comme document de rfrence.

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.5.2 Vrifier si l'analyse des cots et des avantages du projet a t faite dans le but d'valuer la faisabilit sur le plan conomique de chaque solution de rechange.

  • les hypothses et les contraintes relatives au caractre raisonnable de l'analyse cots/avantages; 
  • les cots du systme et de l'utilisateur couvrent toutes les tapes du cycle de vie;
  • les cots estimatifs de la solution de rechange comprennent toutes les amliorations du matriel et du logiciel qui seront ncessaires au soutien de cette solution de rechange;
  • les cots estimatifs de la solution de rechange comprennent les cots de la scurit et des contrles internes, de la prparation et de l'entre des donnes, de la conversion des fichiers, des essais, des activits parallles, de l'acceptation et les cots connexes;
  • la base ayant servi au calcul et l'estimation est raisonnable;
  • les utilisateurs, les concepteurs et les personnes charges de mettre le systme en place sont d'accord sur les cots du systme, les avantages et les ententes contractuelles.
Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.5.3 Veiller ce que l'analyse des cots et des avantages du projet tienne compte des incidences sur les ressources humaines. Vrifier si les cots estimatifs de chaque solution de rechange comprennent :

  • de la formation et
  • le redploiement de l'effectif.
Oui Non S/O Observations Renvois
         
Critre : 2.A.6 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que l'analyse des cots/avantages est fonde sur des donnes prcises et compltes, et s'ils approuvent la solution de rechange recommande.

tape de vrification : 2.A.6.1 Le document des cots et des avantages a-t-il t examin par le comit directeur ou les dtenteurs du pouvoir d'approbation? Ces personnes acceptent-elles l'autre solution de traitement recommande, et conviennent-elles de la ncessit de continuer le projet? Noter toute acceptation conditionnelle pour effectuer un suivi dans les tapes venir.

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.6.2 L'quipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernes?

Oui Non S/O Observations Renvois
         
Critre : 2.A.7 Dterminer si le gestionnaire responsable du projet s'est inspir de la solution de rechange recommande dans l'analyse des cots/avantages pour prparer un sommaire des aptitudes du personnel (aptitudes administratives et techniques requises, niveau de comptence requis, nombre d'employs requis, niveau d'autorisation ncessaire).

tape de vrification : 2.A.7.1 Le gestionnaire du projet a-t-il prpar un rsum des comptences du personnel?

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.7.2 Le rsum des comptences du personnel porte-t-il sur les points suivants :

  • comptences ncessaires (administratives et techniques)
  • niveaux de comptences ncessaires
  • nombre d'employs ncessaires
  • niveau de pouvoir ncessaire.
Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.7.3 La documentation sur le projet montre-t-elle que les comptences des employs affects au projet (en qualit de membres de l'quipe, du comit directeur ou de dtenteurs du pouvoir d'approbation) sont conformes celles qui figurent dans le rsum des comptences du personnel?

Oui Non S/O Observations Renvois
         
Critre : 2.A.8 Dterminer si le calendrier des runions du comit directeur (ou un document de ce genre) indique la date des runions prvues, ainsi que les questions qui seront l'ordre du jour.

tape de vrification : 2.A.8.1 Un document sur le calendrier des runions du comit directeur a-t- il t prpar et communiqu toutes les parties intresses, y compris la gestion de l'informatique et la gestion des utilisateurs?

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.8.2 Examiner les procs-verbaux des runions du comit et noter les points suivants :

  • la prsence de reprsentants de la gestion de l'informatique et de la gestion des utilisateurs chaque runion;
  • la tenue rgulire de runions.
Oui Non S/O Observations Renvois
         
Critre : 2.A.9 Dterminer si le rapport sur l'tude de faisabilit (ou un document de ce genre) compare la ralisation du projet au plan de travail contenu dans le rapport sur le lancement du projet.

tape de vrification : 2.A.9.1 Un rapport d'tape de l'tape de faisabilit a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.9.2 Vrifier si ce document contient au moins les points suivants :

  • utilisation relle des ressources, en comparaison avec le plan; raisons des carts enregistrs;
  • jalons rels atteints en comparaison avec le plan; raisons des carts enregistrs;
  • plan dtaill de l'tape de conception gnrale, avec renvois aux activits suivantes :
    • analyse et spcification des exigences dtailles de l'utilisateur,
    • tablissement des processus de contrle des changements,
    • mise jour de l'analyse cots/avantages,
    • obtention de l'approbation de la gestion;
  • mise jour des budgets et raisons de tout changement;
  • mise jour du calendrier et raisons de tout changement;
  • recommandation de continuer ou d'arrter le projet.
Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.9.3 Vrifier l'utilisation relle des ressources en se servant des documents de base.

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.9.4 Vrifier si le budget et le calendrier mis jour correspondent l'tude de faisabilit et l'analyse cots/avantages.

Oui Non S/O Observations Renvois
         
Critre : 2.A.10 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que l'tude de faisabilit (ou un document semblable) est fonde sur des donnes prcises et compltes, et s'ils l'approuvent.

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

Oui Non S/O Observations Renvois
         

tape de vrification : 2.A.10.2 L'quipe de projet a-t-elle pris des mesures pour consulter toutes les parties concernes?

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

Oui Non S/O Observations Renvois
         

Objectif : 2.B Dterminer si les donnes traites et emmagasines par le systme sont compltes, prcises et dment autorises, et si des mesures de scurit, de protection des renseignements personnels et d'accs l'information sont prvues.

Critre : 2.B.1 Dterminer si la fiche de contrle (ou un document de ce genre) indique les mesures de contrle prvues.

tape de vrification : 2.B.1.1 L'tude de faisabilit fait-elle tat de la ncessit de prparer un document de spcification des contrles du traitement du systme ou un document du genre?

Oui Non S/O Observations Renvois
         
Critre : 2.B.2 Dterminer si le reprsentant des utilisateurs a pris bonne note des mesures de scurit, de protection des renseignements personnels et d'accs l'information.

tape de vrification : 2.B.2.1 Dterminer si l'nonc du niveau de scurit, 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 dtenteurs du pouvoir d'approbation.

Oui Non S/O Observations Renvois
         

Objectif : 2.C Dterminer si le systme est exploit de faon efficace, efficiente et conomique.

Critre : 2.C.1 Dterminer si la configuration de base (ou un document de ce genre) fait tat des exigences en matire de contrle de la gestion du systme.

tape de vrification : 2.C.1.1 L'tude de faisabilit reconnat-elle la ncessit d'un document des spcifications des contrles de gestion du systme, ou d'un document du genre?

Oui Non S/O Observations Renvois
         





Annexe D : Programme de vrification de l'tape de conception gnrale

tape : 3. Conception gnrale

Objectif : 3.A S'assurer que la conception gnrale du systme s'inspire des rsultats obtenus par l'tude de faisabilit, qu'elle permette de produire une description fonctionnelle des processus manuels et informatiques, et qu'elle permette une analyse globale du systme pouvant tre utilise pour obtenir un engagement une laboration ultrieure.

Critre : 3.A.1 Les spcifications des systmes doivent figurer dans un rapport sur les spcifications des systmes, ou dans un document de ce genre.

tape de vrification : 3.A.1.1 Un document des spcifications des systmes a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.1.2 Vrifier si ce document contient au moins les points suivants :

  • Objectifs et porte des systmes.
  • Considrations gnrales sur les concepts et la conception des systmes.
  • Tableau indiquant la structure des fonctions en termes des processus.
  • Diagramme de cheminement des donnes logiques, indiquant le cheminement dans les processus et les stocks de donnes au niveau des lments de donnes.
  • Description des processus comportant les dfinitions compltes et dtailles des processus s'appliquant tous les cas de gestion concerns. Ces descriptions comprendront les algorithmes et les contrles de la validit.
  • Interface des systmes: Dfinitions au niveau des lments de donnes.
  • Entres et sorties de systmes. Les dfinitions au niveau des lments de donnes pour le mode seront utilises pour les entres et les sorties spcifies.
  • Stocks de donnes. Dfinitions des stocks de donnes logiques au niveau des lments de donnes.
  • Volumes, synchronisations, maxima et minima, qualit spcifis pour les entres, les sorties et les stocks de donnes.
  • Niveaux de service. Description complte des exigences en matire de performance. Utilisation dans les tapes subsquentes pour confirmer la faisabilit technique et les exigences en ressources du systme.
  • Exigences en matire de vrification, de contrle et de scurit.
  • Exigences en matire de mise en oeuvre, y compris la conversion.

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

Oui Non S/O Observations Renvois
         
Critre : 3.A.2 Le caractre exact et complet des spcifications des systmes doit tre reconnu l'chelon appropri des utilisateurs et de la gestion de l'informatique.

tape de vrification : 3.A.2.1 Le document des spcifications des systmes a-t-il t examin par le comit directeur ou les dtenteurs du pouvoir d'approbation? Ceux-ci reconnaissent-ils la ncessit de continuer le projet? Noter toute acceptation conditionnelle pour effectuer un suivi dans les tapes venir.

Oui Non S/O Observations Renvois
         
Critre : 3.A.3 Le dictionnaire ou le rpertoire des donnes doit tre mis jour pour reflter le contenu des spcifications des systmes.

tape de vrification : 3.A.3.1 Le dictionnaire ou le rpertoire de donnes a-t-il t mis jour et contient-il les spcifications des systmes?

Oui Non S/O Observations Renvois
         
Critre : 3.A.4 Toutes les comptences ncessaires doivent tre mises la disposition du projet.

tape de vrification : 3.A.4.1 Les comptences du personnel employ au projet (en qualit de membres de l'quipe, de membres du comit directeur ou de dtenteurs du pouvoir d'approbation) continuent-elles rpondre aux exigences spcifies dans le rsum des comptences du personnel?

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

tape de vrification : 3.A.5.1 Un calendrier des runions du comit directeur a-t-il t prpar et communiqu toutes les parties intresses, y compris la gestion de l'informatique et la gestion cliente?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.5.2 Assister aux runions du comit ou en examiner les procs-verbaux, en notant les points suivants :

  • la prsence des reprsentants de la gestion de l'informatique et de la gestion des utilisateurs chaque runion;
  • la tenue rgulire de runions.
Oui Non S/O Observations Renvois
         
Critre : 3.A.6 L'tat du projet par rapport au budget et au calendrier contenus dans le document connexe de l'tape de faisabilit doit figurer dans le rapport sur les progrs raliss l'tape d'analyse gnrale ou dans un document de ce genre.

tape de vrification : 3.A.6.1 Un document des progrs raliss l'tape de conception gnrale a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.6.2 Vrifier si ce document contient au moins les points suivants :

  • utilisation relle des ressources, en comparaison avec le plan; raisons des carts enregistrs;
  • jalons rels atteints, en comparaison avec le plan; raisons des carts enregistrs;
  • plan dtaill de l'tape de conception dtaille, avec renvois aux activits suivantes :
    • mise jour du dictionnaire ou du rpertoire de donnes,
    • excution de la conception finale de toutes les entres et de toutes les sorties,
    • laboration du plan dtaill de tests,
    • vrifier si les normes de scurit ont t respectes
    • dvelopper un plan de tests dtaills
    • mise jour des plans et budgets des projets,
    • mise jour des analyses cots/avantages,
    • obtention de l'approbation de la gestion;
  • plan prliminaire pour l'tape de mise en oeuvre, y compris les points suivants :
    • relev des procdures manuelles laborer,
    • manuels touchs,
    • besoins en matire d'installations,
    • besoins en matire de communications,
    • formation,
  • budget mis jour et raisons de tout changement,
  • calendrier mis jour et raisons de tout changement,
  • analyse des cots/ avantages mise jour,
  • recommandation de continuer ou d'arrter le projet.
Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.6.3 Vrifier l'utilisation relle des ressources avec renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.6.4 Le budget et le calendrier mis jour correspondent-ils l'analyse cots/avantages mise jour?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.6.5 Vrifier l'analyse cots/avantages mise jour par rapport l'analyse cots/avantages provenant de l'tape prcdente et aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.6.6 Dterminer si l'analyse cots/avantages mise jour tient compte des exigences se rapportant aus incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critre : 3.A.7 Le caractre exact et complet du document d'tape de l'tape d'analyse et l'accord qu'il a entran doivent tre reconnus l'chelon appropri des utilisateurs et de la gestion de l'informatique.

tape de vrification : 3.A.7.1 Le document d'tape de l'tape de conception gnrale a-t-il t examin par le comit directeur ou les dtenteurs du pouvoir d'approbation et ceux-ci l'ont accept?

Oui Non S/O Observations Renvois
         
Critre : 3.A.8 Une analyse des incidences sur les ressources humaines est prvue.

tape de vrification : 3.A.8.1 Le plan dtaill pour l'tape de conception dtaille prvoit-il une analyse des incidences sur les ressources humaines? L'analyse prvue vise-t-elle tous les employs qui seront touchs (c'est--dire les employs qui recevront une formation pour le nouveau systme et ceux qui devront tre redploys)?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.A.8.2 Le plan dtaill pour l'tape de conception dtaille prvoit-il la diffusion de renseignements sur le nouveau systme (c'est--dire la communication avec tous ceux qui seront touchs, les rpercussions du systme sur le ministre et sur les employs)?

Oui Non S/O Observations Renvois
         

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

Objectif : 3.B S'assurer que les donnes traites et stockes par le systme soient compltes, exactes et autorises.

Critre : 3.B.1 Les techniques de contrle du traitement doivent figurer dans un rapport sur les spcifications des contrles du traitement du systme ou dans un document de ce genre.

tape de vrification : 3.B.1.1 Un document des spcifications des contrles du traitement a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.B.1.2 Vrifier s'il traite au moins des points suivants (voir l'appendice pour d'autres rfrences des contrles de donnes) :

  1. Caractre complet
    1. Il faut une mthode permettant de s'assurer que toutes les donnes soient enregistres et releves au dbut.
    2. On doit tablir le contrle prs de la source de l'opration.
    3. On doit rapprocher les sorties et les entres.
    4. Il faut une mthode permettant de s'assurer que les corrections soient entres dans le systme pour toutes les erreurs identifies.
    5. On doit veiller synchroniser les soumissions de donnes et la distribution des sorties avec le traitement.
    6. On doit mettre en place des procdures d'examen indpendant de la forme et du caractre complet des rapports de sorties.
  2. Exactitude
    1. Il faut des procdures permettant de prvenir les erreurs dans la prparation des entres ou des donnes sources, ainsi que pour dceler et corriger toutes les erreurs importantes qui se sont produites.
    2. Il faut des procdures pour prvenir les erreurs dans la conversion des donnes en une forme se prtant au traitement automatis, ainsi que pour dceler et corriger toutes les erreurs importantes qui se sont produites.
    3. Il faut des procdures permettant d'assurer la transmission exacte des donnes au centre informatique.
    4. Les procdures doivent tre documentes pour assurer le bon fonctionnement de l'quipement informatique, ainsi que la dtection des cas de mauvais fonctionnement et des erreurs de donnes qui en rsultent.
    5. Des procdures doivent assurer l'utilisation de fichiers valides seulement.
    6. Des contrles doivent assurer le maintien de l'exactitude des donnes pendant tout le traitement.
    7. Des procdures doivent assurer la bonne excution des calculs de programmes.
    8. Il faut un systme de contrle sur les oprations manuelles du systme informatique.
    9. Des procdures doivent assurer que toutes les erreurs importantes dceles diverses tapes du systme ont t corriges et que les corrections ont t rentres et bien indiques dans la sortie.
    10. Des procdures doivent garantir que tous les rapports de sortie requis sont livrs aux ministres clients appropris.
  3. Autorisation
    1. Assurer le traitement des donnes autorises seulement.
    2. On devra avoir dtermin les classifications de niveau de scurit, de protection des renseignements personnels et d'accessibilit (voir 2.B1.2.1), en ce qui concerne les donnes se rapportant au systme, et on devra avoir conu les mesures appropries pour assurer le stockage, la transmission, l'accs, la protection et la destruction qui conviennent ces donnes.
    3. Il faut une mthode permettant de relever et de retrouver les dossiers de fichiers, ainsi que les documents d'entres ou de sorties relis au traitement d'une opration donne, ou l'accumulation d'un total donn.
  4. Appui/Relance
    1. Les procdures de sauvegarde ou de relance des systmes doivent tre documentes et on doit prparer les plans de formation s'y rapportant.
    2. Les procdures de prparation des donnes, de transcription et de contrle des donnes, ainsi que de distribution des sorties doivent tre documentes, et des plans de formation connexes doivent tre prpars.
  5. Piste de vrification
    1. Il faut une mthode permettant de reconnatre et de retrouver les dossiers de fichiers, ainsi que les documents d'entres ou de sorties relis au traitement d'une opration donne, ou l'accumulation d'un total donn.

Note : Diffrents concepts en matire de contrle s'appliquent diffrents genres de systme (par exemple, par lots plutt qu'en direct). La bibliographie l'appendice I renferme des ouvrages sur les contrles pour divers genres de systmes.

Oui Non S/O Observations Renvois
         
Critre : 3.B.2 Le caractre exact et complet des spcifications des techniques de contrle du traitement doit tre reconnu l'chelon appropri des utilisateurs et de la gestion de l'informatique.

tape de vrification : 3.B.2.1 Le document des spcifications des contrles du traitement a-t-il t examin par le comit directeur ou les dtenteurs 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
         
Critre : 3.C.1 Les techniques de contrle de la gestion des systmes doivent tre indiques dans un document sur les spcifications des contrles de la gestion des systmes ou dans un document du genre.

tape de vrification : 3.C.1.1 Un document des spcifications des contrles de la gestion des systmes a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 3.C.1.2 Vrifier si ce document traite au moins des points suivants :

  1. Efficience
    1. Une norme ou une srie de normes permettant de mesurer l'efficience du systme doivent exister.
    2. Il faut un moyen de comparer le rendement aux normes et de faire rapport sur les carts.
    3. Il faut des procdures de suivi l'intention des gestionnaires l'gard des dviations des normes et de la consignation des mesures prises.
  2. Efficacit
    1. Il faut tablir des normes d'efficacit relatives aux objectifs du systme.
    2. Il faut tablir une mthode permettant de dceler les cas o les systmes ne peuvent plus atteindre leurs objectifs initiaux et de faire rapport sur ces cas.
  3. conomie
    1. La gestion doit mettre en oeuvre des procdures officielles pour l'examen priodique de l'conomie de ses projets et des applications du systme qui en dcoulent.
Oui Non S/O Observations Renvois
         
Critre : 3.C.2 Le caractre exact et complet des spcifications des techniques de contrle de la gestion des systmes doit tre reconnu l'chelon appropri des utilisateurs et de la gestion de l'informatique.

tape de vrification : 3.C.2.1 Le document des spcifications des contrles de la gestion des systmes a-t-il t examin par le comit directeur ou les dtenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accept? Noter toute acceptation conditionnelle pour effectuer un suivi dans les tapes venir.

Oui Non S/O Observations Renvois
         





Annexe E : Programme de vrification de l'tape de conception dtaille

tape : 4. Conception dtaille

Objectif : 4.A. Dterminer si une conception dtaille a t mise au point partir des caractristiques fonctionnelles tablies au moment de la conception gnrale.

Critre : 4.A.1 Dterminer si le rapport sur la conception dtaille (ou un document de ce genre) fait tat des caractristiques de la programmation.

tape de vrification : 4.A.1.1 Un document sur la conception dtaille des systmes a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.1.2 Vrifier si ce document couvre au moins les points suivants :

  • Acheminement des systmes et description par fonction.
  • Dictionnaire des lments de donnes.
  • Fichiers de systmes.
  • Entres de systmes, y compris la conception des formules et des crans.
  • Sorties de systmes, y compris la conception des formules, des rapports et des crans.
  • Spcifications de l'interface de systmes.
  • Spcifications des logiciels de systmes.
  • Spcifications du matriel.
  • Spcifications des communications.
  • Spcifications de l'installation pour la gestion des systmes.
  • Spcifications de la vrification, du contrle et de la scurit.
  • Spcifications du module de traitement en commun.
  • Spcifications de la conversion.
Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.1.3 Vrifier si les spcifications des systmes pour chaque application du systme sont claires, compltes et uniformes.

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.1.4 valuer le caractre raisonnable de la logique du programme intgre dans les applications par l'examen des graphiques d'acheminement, des tables de dcisions ou des rapports narratifs.

Oui Non S/O Observations Renvois
         
Critre : 4.A.2 Dterminer si les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que les caractristiques sont prcises et compltes.

tape de vrification : 4.A.2.1 Le document de conception dtaille des systmes a-t-il t examin par le comit directeur ou les dtenteurs 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
         
Critre : 4.A.3 Dtermineer si le dictionnaire ou rpertoire des donnes a t mis jour en fonction du document sur les caractristiques de la conception dtaille.

tape de vrification : 4.A.3.1 Le dictionnaire ou le rpertoire de donnes a-t-il t mis jour et contient-il les spcifications dtailles des systmes?

Oui Non S/O Observations Renvois
         
Critre : 4.A.4 Le plan de mise l'essai (ou un document de ce genre) indique les mises l'essai prvues.

tape de vrification : 4.A.4.1 Un plan des tests a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.4.2 Vrifier si ce document contient au moins les points suivants, pour les tests des programmes et des systmes, ainsi que pour le volume et l'aspect oprationnel :

  • Vue d'ensemble des logiciels tester, y compris ceux du fournisseur et ceux de conversion, ainsi que l'environnement de travail o ils s'inscrivent. - Calendrier des tests.
  • Emplacements avec les exigences en matire de dplacements spciaux et d'hbergement.
  • Matriaux et fournitures, y compris quipements, logiciels, installations de stockage (magntique et physique), personnel, documentation, entres tester, chantillons de sorties et formules spciales.
  • Exigences en matire de formation.
  • Liste des exigences de l'utilisateur tester.
  • Liste des exigences oprationnelles tester.
  • Vue d'ensemble de la progression des tests.
  • Description des tests mener pour chaque exigence, y compris le type d'entres utiliser, la mthode d'enregistrement des rsultats, les contraintes telles que celles d'quipement ou de disponibilit du personnel, les critres d'valuation, ainsi que toute manipulation des donnes ncessaire la prsentation de rapports.
Oui Non S/O Observations Renvois
         
Critre : 4.A.4 Le plan de mise l'essai (ou un document de ce genre) indique les mises l'essai prvues.

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

  • la norme relative aux plans de test des systmes et la norme relative aux plans de test des units telles qu'nonces dans <<The Institute for Electrical System Test Plan Standard and Unit Test Plan Standard>>.
  • Le guide d'Auerbach A Standard for Testing Application Software.
Oui Non S/O Observations Renvois
         
Critre : 4.A.5 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le plan de mise l'essai est prcis et complet.

tape de vrification : 4.A.5.1 Le document de plan des tests a-t- il t examin par le comit directeur ou les dtenteurs 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
         
Critre : 4.A.6 Le plan de mise l'essai tient compte des besoins des utilisateurs.

tape de vrification : 4.A.6.1 Tous les lments du document des exigences des utilisateurs sont-ils assujettis des tests? Des tests adquats peuvent inclure : des revues de projets, simulations et prototypes. L o des points ne sont pas tests, vrifier si une explication a t donne au comit directeur ou aux dtenteurs du pouvoir d'approbation et accepte par ceux-ci.

Oui Non S/O Observations Renvois
         
Critre : 4.A.7 Toutes les ressources humaines requises ont t affectes la ralisation du projet.

tape de vrification : 4.A.7.1 Les comptences du personnel employ au projet (en qualit de membres de l'quipe, de membres du comit directeur ou de dtenteurs du pouvoir d'approbation) rpondent-elles encore aux exigences spcifies dans le rsum des comptences du personnel?

Oui Non S/O Observations Renvois
         
Critre : 4.A.8 Le calendrier des runions du comit directeur (ou un document de ce genre) fait tat de toutes les runions prvues, ainsi que des questions qui seront l'ordre du jour.

tape de vrification : 4.A.8.1 Un calendrier des runions du comit directeur a-t-il t prpar et communiqu toutes les parties intresses, y compris la gestion de l'informatique et la gestion des clients?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.8.2 Assister aux runions du comit ou en examiner les procs-verbaux, en notant les points suivants :

  • la prsence des reprsentants de la gestion de traitement lectronique des donnes (TED) et de la gestion des clients chaque runion;
  • la tenue rgulire de runions.
Oui Non S/O Observations Renvois
         
Critre : 4.A.9 Le rapport sur la conception dtaille (ou un document de ce genre) examine le projet par rapport au budget et au calendrier tablis dans le rapport sur la conception gnrale.

tape de vrification : 4.A.9.1 Un document d'tape de l'tape de conception dtaille a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.9.2 Vrifier si ce document contient au moins les points suivants : 

  • utilisation relle des ressources, en comparaison avec celles prvues, et raisons des carts enregistrs;
  • jalons rels atteints, en comparaison avec ceux prvus; raisons des carts enregistrs;
  • plan dtaill de l'tape de mise en oeuvre, notamment avec renvoi aux activits suivantes :
    • conception des structures, de la logique et du cheminement de chaque composant du systme,
    • conception de toutes les bases de donnes et de tous les fichiers,
    • valuation de la performance des systmes et des exigences en matires de ressources; confirmation que les niveaux de service seront atteints,
    • conception des outils de conversion,
    • programmes de codage et de tests,
    • achat et tests des logiciels du fournisseur,
  • intgration des programmes dans les sous-systmes et systmes,
    • rdaction de manuels et procdures des utilisateurs,
    • rdaction de manuels de conversion et de formation, ainsi que de manuels oprationnels,
    • conduite de tests de volume et de tests oprationnels,
    • documentation des programmes et des systmes,
    • mise jour des plans et des budgets du projet,
    • mise jour des analyses cots/avantages,
    • obtention de l'approbation de la gestion;
  • plan prliminaire pour l'tape de mise en place, y compris les points suivants :
    • conversion des fichiers
    • formation
    • manuels d'instruction
    • redploiement de l'effectif
    • date de mise en service
  • budget mis jour et raisons de tout changement
  • calendrier mis jour et raisons de tout changement
  • analyse des cots et avantages mise jour
  • recommandation de continuer ou d'arrter le projet.
Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.9.3 Vrifier l'utilisation relle des ressources avec renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.9.4 Vrifier si le budget et le calendrier mis jour correspondent l'analyse cots/avantages mise jour.

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.9.5 Comparer l'analyse cots/avantages mise jour l'analyse cots/avantages provenant de l'tape prcdente et des documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.9.6 L'analyse cots/avantages mise jour tient-elle compte des exigences se rapportant l'incidence sur les ressources humaines?

Oui Non S/O Observations Renvois
         
Critre : 4.A.10 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la conception dtaille renferme des donnes prcises et compltes, et s'ils l'approuvent.

tape de vrification : 4.A.10.1 Le document d'tape de l'tape de conception dtaille a-t-il t examin par le comit directeur ou les dtenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accept?

Oui Non S/O Observations Renvois
         
Critre : 4.A.11 Dterminer si une analyse de l'incidence sur les ressources humaines a t effectue.

tape de vrification : 4.A.11.1 Une analyse des incidences sur les ressources humaines a-t- elle t effectue?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.A.11.2 Le comit directeur ou les dtenteurs du pouvoir d'approbation ont-ils examin les conclusions de l'analyse?

Oui Non S/O Observations Renvois
         

Objectif : 4.B Dterminer si les donnes traites et emmagasines par le systme sont compltes, prcises et dment autorises.

Critre : 4.B.1 Dterminer si le plan de mise l'essai (ou un document de ce genre) fait tat des mthodes de contrle du traitement nonces dans le rapport sur le contrle du traitement.

tape de vrification : 4.B.1.1 Un plan des tests a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.B.1.2 Vrifier s'il traite des exigences en matire de contrle indiques dans le document des spcifications du contrle du traitement (voir l'objectif 3.B.1).

Oui Non S/O Observations Renvois
         

Objectif : 4.C. Le systme est exploit de faon efficace et efficiente.

Critre : 4.C.1 Le plan de mise l'essai (ou un document de ce genre) fait tat des mthodes de contrle ncessaires pour respecter les exigences nonces dans le rapport sur le contrle de gestion du systme.

tape de vrification : 4.C.1.1 Un document de plan des tests a-t- il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 4.C.1.2 Vrifier s'il traite des exigences en matire de contrle indiques dans le document des spcifications des contrles de la gestion des systmes (voir l'objectif 3.C.1).

Oui Non S/O Observations Renvois
         





Annexe F : Programme de vrification de l'tape de la mise en oeuvre

tape : 5. Mise en oeuvre

Objectif : 5.A Tous les formulaires, manuels, programmes et documents de formation appropris ont t prpars partir des caractristiques de l'analyse dtaille.

Critre : 5.A.1 Tous les manuels et autres documents requis ont t prpars avant l'installation du systme.

tape de vrification : 5.A.1.1 Dterminer si les lments suivants ont t prpars :

  • instruments de conversion
  • manuels de l'utilisateur
  • manuels de conversion
  • manuels de formation
  • manuels d'oprations
  • documentation des programmes et systmes.
Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.1.2 Vrifier si le manuel dutilisation :

  • dcrit les fonctions avec suffisamment de dtail
  • renferme de la terminologie non informatique
  • indique quand et comment il doit tre utilis
  • sert de document de rfrence - explique comment prparer les donnes d'entre et les paramtres
  • explique comment interprter les sorties
  • dcrit l'application en dtail
  • dcrit comment corriger les erreurs
  • dcrit comment reconstituer les oprations.
Oui Non S/O Observations Renvois
         
Critre : 5.A.2 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que les manuels et documents requis renferment des donnes compltes et prcises.

tape de vrification : 5.A.2.1 Les manuels et sorties ncessaires ont-ils t examins par tous les membres de l'quipe de projet et ceux-ci les ont-ils accepts? Noter toute acceptation conditionnelle pour effectuer un suivi dans l'tape suivante.

Oui Non S/O Observations Renvois
         
Critre : 5.A.3 Le rapport sur la mise l'essai (ou un document de ce genre) fait tat des rsultats obtenus.

tape de vrification : 5.A.3.1 Un document de rapport sur les tests a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.3.2 Vrifier si ce document couvre au moins les points suivants en ce qui concerne les tests des programmes et des systmes, ainsi que les tests du volume et des oprations :

  • rsultats des tests
  • raisons pour les tests non raliss
  • action du suivi adopte le cas chant d'aprs les rsultats des tests.
Oui Non S/O Observations Renvois
         
Critre : 5.A.4 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la mise l'essai renferme des donnes prcises et compltes.

tape de vrification : 5.A.4.1 Le document de rapport sur les tests a-t-il t examin par le comit directeur ou les dtenteurs 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
         
Critre : 5.A.5 Toutes les ressources humaines ncessaires ont t affectes la ralisation du projet.

tape de vrification : 5.A.5.1 Les comptences du personnel employ au projet (en qualit de membres de l'quipe, de membres du comit directeur ou de dtenteurs du pouvoir d'approbation) rpondent-elles encore aux exigences spcifies dans le rsum des comptences du personnel?

Oui Non S/O Observations Renvois
         
Critre : 5.A.6 Le calendrier des runions du comit directeur (ou un document de ce genre) indique la date de toutes les runions prvues, ainsi que les questions qui seront l'ordre du jour.

tape de vrification : 5.A.6.1 Un calendrier des runions du comit directeur a-t-il t prpar et communiqu toutes les parties intresses, y compris la gestion de l'informatique et la gestion des clients?

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.6.2 Assister aux runions du comit ou en examiner les procs-verbaux, en notant les points suivants :

  • la prsence de reprsentants de la gestion de l'information de la gestion des clients chaque runion;
  • la tenue rgulire de runions.
Oui Non S/O Observations Renvois
         
Critre : 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 dtaille.

tape de vrification : 5.A.7.1 Un document d'tape de l'tape de mise en oeuvre a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.7.2 Vrifier si ce document contient au moins les points suivants :

  • utilisation relle des ressources, en comparaison avec le plan; raisons des carts enregistrs;
  • jalons rels atteints, en comparaison avec le plan; raisons des carts enregistrs;
  • plan dtaill de l'tape de mise en place, avec renvoi aux activits suivantes :
    • conversion des fichiers, y compris tout rapprochement et chantillonnage des rsultats;
    • formation, y compris les calendriers et la distribution des documents;
    • distribution des manuels d'utilisation et des manuels d'oprations;
    • redploiement du personnel;
    • calendrier de mise en service;
  • budget mis jour et raisons de tout changement;
  • calendrier mis jour et raisons de tout changement;
  • analyse cots/avantages mise jour;
  • recommandation de continuer ou d'arrter le projet.
Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.7.3 Vrifier l'utilisation relle des ressources par renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.7.4 Vrifier si le budget et le calendrier mis jour correspondent l'analyse cots/avantages mise jour.

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.7.5 Comparer l'analyse cots/avantages mise jour l'analyse cots/avantages provenant de l'tape prcdente et des documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 5.A.7.6 Dterminer si l'analyse cots/avantages mise jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critre : 5.A.8 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur la mise en oeuvre renferme des donnes prcises et compltes, et s'ils approuvent ce rapport.

tape de vrification : 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 dtenteurs du pouvoir d'approbation? Ceux-ci l'ont-ils accept?

Oui Non S/O Observations Renvois
         

Objectif : 5.B Les principaux contrles de transmission sont efficaces.

Critre : 5.B.1 Exercer de nouveau certains contrles de la validit des donnes.

tape de vrification : 5.B.1.1 Effectuer de nouveau certains tests de contrle de l'intgrit des donnes.

Note : L'appendice I renferme des ouvrages de rfrence qui permettent de dterminer les techniques utiliser pour effectuer de nouveau les contrles choisis, selon la nature et l'environnement du systme. Les systmes en direct exploits en temps rels qui utilisent des systmes de gestion de la base des donnes sous le contrle d'une gestion administrative des donnes distinctes exigent de nouveaux tests plus complexes que les systmes ordinaires de fichier matre sur bande avec entre de lots.

Oui Non S/O Observations Renvois
         

Objectif : 5.C Les principaux contrles exercs sont efficaces.

Critre : 5.C.1 Exercer de nouveau certains contrles de la validit des donnes.

tape de vrification : 5.C.1.1 Effectuer de nouveau certains tests de contrle de l'intgrit du systme.

Note : L'appendice I renferme des ouvrages de rfrence qui permettent de dterminer les techniques utiliser pour effectuer de nouveau les contrles choisis, selon la nature et l'environnement du systme. Les systmes en direct exploits en temps rel qui utilisent des systmes de gestion de la base des donnes sous le contrle d'une gestion administrative des donnes distincte exigent de nouveaux tests plus complexes que les systmes ordinaires de fichier matre sur bande avec entre de lots.

Oui Non S/O Observations Renvois
         





Annexe G : Programme de vrification de l'tape de la mise en place

tape : 6. Mise en place

Objectif : 6.A. Le systme et la conversion de fichiers (le cas chant) passent du stade de dveloppement au stade d'opration et d'entretien.

Critre : 6.A.1. La prcision, l'intgralit et l'authenticit des fichiers crs par voie de conversion sont assures grce l'application des mthodes de contrle appropries.

tape de vrification : 6.A.1.1 Examiner le plan de conversion avant son excution en se rapportant la liste des contrles minimaux du traitement des systmes et vrifier si des techniques de contrle sont incluses dans le processus de conversion afin de rpondre toutes les questions de contrle.

  • Il s'agit ici d'un processus extrmement critique et on ne devrait tolrer aucun doute quant l'intgrit des donnes dans les nouveaux fichiers. On peut devoir utiliser des techniques de contrle telles que la vrification ligne ligne.
Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.1.2 Vrifier que la conversion a t excute selon le plan tabli.

Oui Non S/O Observations Renvois
         
Critre : 6.A.2 La formation a t assure conformment au calendrier prpar cet effet.

tape de vrification : 6.A.2.1 Vrifier si la formation a t assure selon le calendrier prpar lors de l'tape de mise en oeuvre et si toute variation a reu l'accord de la gestion des clients.

Oui Non S/O Observations Renvois
         
Critre : 6.A.3 L'installation a t effectue conformment au calendrier prpar cet effet.

tape de vrification : 6.A.3.1 Les mises en place ont-elles t faites selon le calendrier prpar lors de l'tape de mise en oeuvre? Les variations ont-elle t approuves par la gestion des clients?

Oui Non S/O Observations Renvois
         

tape de vrification : 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 faon indpendante, chacun doit faire l'objet d'une signature d'approbation de la part de son utilisateur.

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

tape de vrification : 6.A.4.1 Un rapport d'tape de l'tape de mise en place a-t-il t prpar et communiqu?

Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.4.2 Vrifier si ce document contient au moins les points suivants :

  • utilisation relle des ressources, en comparaison avec le plan; raisons des carts enregistrs;
  • jalons rels atteints, en comparaison avec le plan; raisons des carts enregistrs;
  • budget mis jour et raisons de tout changement;
  • calendrier mis jour et raisons de tout changement;
  • analyse cots/avantages mise jour;
  • recommandation de poursuivre ou d'arrter le projet.
Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.4.3 Vrifier l'utilisation relle des ressources par renvoi aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.4.4 Vrifier si le budget et le calendrier mis jour correspondent l'analyse cots/avantages mise jour.

Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.4.5 Comparer l'analyse cots/avantages mise jour l'analyse cots/avantages provenant de l'tape prcdente et aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 6.A.4.6 Dterminer si l'analyse cots/avantages mise jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         
Critre : 6.A.5 Les utilisateurs et les gestionnaires responsables du traitement des donnes estiment que le rapport sur l'installation renferme des donnes prcises et compltes, et s'ils approuvent ce rapport.

tape de vrification : 6.A.5.1 Le caractre exact et complet du rapport d'tape de l'tape de mise en place et l'accord qu'il a entran doivent tre reconnus l'chelon appropri des utilisateurs et de la gestion de l'informatique.

Oui Non S/O Observations Renvois
         





Annexe H : Programme de vrification de l'tape des activits postrieures la mise en place

tape : 7. Activits postrieures la mise en place

Objectif : 7.A Le systme est exploit conformment aux objectifs d'analyse et autres critres d'valuation, et si les cots/avantages prvus sont atteints.

Critre : 7.A.1 L'installation a t suivie d'un examen, et si les rsultats ont t communiqus aux membres de la haute direction.

tape de vrification : 7.A.1.1 Un rapport sur les activits postrieures la mise en place, ou un document de ce genre, a-t-il t prpar?

Oui Non S/O Observations Renvois
         

tape de vrification : 7.A.1.2 Vrifier si ce document contient les points suivants :

  • documentation des ralisations relles du systme;
  • comparaison de ces ralisations avec les objectifs originaux;
  • recommandation d'amliorations;
  • utilisation relle des ressources, en comparaison avec le plan original; raisons des carts enregistrs;
  • jalons rels atteints, en comparaison avec le plan; raisons des carts enregistrs;
  • analyse cots/avantages mise jour.
Oui Non S/O Observations Renvois
         

tape de vrification : 7.A.1.3 Vrifier l'utilisation relle des ressources dans les documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 7.A.1.4 Comparer l'analyse cots/avantages mise jour aux documents sources.

Oui Non S/O Observations Renvois
         

tape de vrification : 7.A.1.5 Dterminer si l'analyse cots/avantages mise jour tient compte des exigences se rapportant aux incidences sur les ressources humaines.

Oui Non S/O Observations Renvois
         





Annexe I : Bibliographie

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

 




Appendix J : Politiques et normes du CT et du BCG

Conseil du trsor et bureau du controleur gnral politiques et normes applicables aux systemes en cours d'laboration

Aperu de la politique de gestion de l'information - Orientation stratgique en matire de gestion de la technologie de l'information dans le gouvernement fdral 1987

  • Conseil du Trsor

Circulaires du Conseil du Trsor:

  • 1980-33 Informatique - faire ou faire faire
  • 1982-17 Procdures - faire ou faire faire en informatique
  • 1983-36 Approbation des projets d'laboration de systmes informatiques
  • 1985-8 Politique sur les micro-ordinateurs
  • 1987-47 Politique concernant ls normes sur la technologie de l'information
  • 1987-52 Examen de la mise en oeuvre de la politique sur la scurit
  • 1988-25 laboration, acquisition et exploitation de logiciels pour les systmes de gestion financire

laboration de systmes financiers:

Critres communs d'valuation des sytmes de gestion financire (CGC 1197)

  • Bureau du contrleur gnral
  • 1988

Modules du Manuel des systmes de gestion financire, Bureau du contrleur gnral : 

  • Gestion des recettes 1989 (CGC 1193)
  • Gestion des dpenses (CGC 1207)
  • Planification financire et budgtisation ( venir)

Direction de l'information et des systmes de gestion financire - Mthodologie d'apprciation des risques

  • Bureau du contrleur gnral
  • 1989

bauche: Factors for the Successful Implementation of a Financial Systems

  • Direction de l'information et des systmes de gestion financire
  • Bureau du contrleur gnral
  • 1989
  • l'bauche n'a pas t traduite

Diapositives: Stratgie d'information financire compter des annes 90

  • Direction de l'information et des systmes de gestion financire
  • Bureau du contrleur gnral
  • 1989

Voir aussi Circulaire du Conseil du Trsor, no 1988-25 ci-dessus

Guide de vrification du processus de gestion

  • Bureau du contrleur gnral
  • 1987

Guide de vrification des systmes en cours d'laboration

  • bauche
  • Bureau du contrleur gnral
  • 1988

Manuel de la politique administrative - chapitre 440 - Informatique

  • Conseil du Trsor
  • 1978

Manuel de la politique administrative - chapitre 540 - Gestion et contrle des projets 

  • Conseil du Trsor
  • 1978

Normes de vrification dans le gouvernment du Canada (CGC 1009)

  • Bureau du contrleur gnral
  • 1982

Normes et politique de scurit

  • Secrtariat du Conseil du Trsor
  • 1989

Notice d'interprtation de la politique: Vrification avant la mise en oeuvre

  • NIP 1984-03
  • Bureau du contrleur gnral

Politique du gouvernement sur la scurit

  • Conseil du Trsor
  • 1987

Scurit au gouvernement du Canada - Normes provisoires de scurit

  • Conseil du Trsor
  • 1987