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

Cette page a été archivée.

D�tail du Processus d'�laboration des systemes

Introduction

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

Le cycle d'�laboration des syst�mes

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

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

• Lancement d'un projet
• �tude de faisabilit�
• Conception g�n�rale
• Conception d�taill�e
• Mise en oeuvre
• Mise en place
• Activit�s post�rieures � la mise en place

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

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

Cr�ation de prototypes

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

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

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

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

Gestion des donn�es

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

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

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

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

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

Figure 3 : CES conventionnel - Produits attendus par �tape

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

Description des �tapes

1. �tape de lancement d'un projet

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

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

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

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

2. �tape de faisabilit�

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

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

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

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

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

3. �tape de conception g�n�rale

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

Ce travail exigera :

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

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

4. �tape de conception d�taill�e

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

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

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

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

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

5. �tape de mise en oeuvre

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

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

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

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

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

6. �tape de mise en place

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

7. �tape d'activit�s post�rieures � la mise en place

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

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

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

Conclusion de la description des �tapes

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

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

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

R�les

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

Gestion

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

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

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

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

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

Concepteur/analyste

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

Programmeur

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

Utilisateurs

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

Processus de s�curit� dans le minist�re

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

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

Gestionnaire ou administrateur des donn�es dans le minist�re

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

Administrateur de la base de donn�es du minist�re

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

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

V�rificateurs internes

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

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

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

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

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