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


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.