Publicité
Publicité

Contenu connexe

Publicité

Acquisition, Conception et Implantation des SI

  1. CISA Acquisition, Conception et Implantation des Systèmes d’Information
  2. Objectifs  A la fin de cette leçon ,vous serez capable de :  Décrire les projets, programmes, dossiers ou portefeuille.  Décrire les processus de gestion de projet  Décrire les formes d’organisation de projet  Décrire le cycle de développement des applications d’affaires  Définir les termes MPO, EPF,  …
  3. Réalisation d’affaires  Un projet est un effort temporaire dans le but de créer un produit, un service ou un résultat unique.  Le management de projet est l’application de connaissances, de compétences, d’outils et de technique aux activités d’un projet afin d’en satisfaire les exigences.  La réalisation de projet est un compromis entre des facteurs majeurs comme les coûts, la qualité, la vitesse, la précision et la fiabilité.
  4. Gestion de dossier et de programme  Un programme est un groupe de projets et de tâches assortis d’un calendrier et qui sont étroitement liés par des objectifs communs et des calendriers et stratégies entrelacés.  L’objectif de la gestion de programme est l’exécution réussie du programme, y compris, entre autres, la gestion :  De la portée, des finances, des calendriers et des objectifs et des livrables du programme  Du contexte et de l’environnement du programme  De la communication et de la culture du programme  De l’organisation du programme
  5. Gestion de dossier et de programme  Un dossier de projets se définit comme « tous les projets exécutés dans l’organisation à un point précis dans le temps ».  Les objectifs de la gestion du dossier de projets sont :  L’optimisation des résultats du dossier de projets  La priorisation et la programmation des projets  La coordination des ressources (internes et externes)  Le transfert de connaissances à travers les projets
  6. Plan de mise en œuvre  Le plan de mise en œuvre fournit l’information dont l’organisation a besoin pour décider si un projet doit aller de l’avant.  Le plan de mise en œuvre initial dérive d’une étude de faisabilité entreprise dans le cadre de la planification ou du lancement du projet.  Il doit être suffisamment détaillé et apporter une justification au démarrage ou à la continuation du projet.  C’est un élément clé du processus de décision tout au long du cycle de vie de tout projet.
  7. Structure de gestion de projet  www.pmi.org : Project Management Body of Knowledge (PMBoK)  www.prince2.com : Projects in a Controlled Environment (PRINCE 2)  www.ipma.ch
  8. Aspects généraux  Un projet est toujours un effort à durée limitée  Un projet peut être complexe et impliquer un élément de risque  Un projet comporte des objectifs, des livrables et des dates de début et de fin spécifiques.  La plupart des projets sont divisibles en phases explicites  Un projet peut être perçu non seulement comme un groupe de tâches complexes, mais aussi comme un système social ou une organisation temporaire.  La gestion de projet comprend des sous-processus comme le lancement, la planification, la coordination, l’exécution, le contrôle, et la clôture
  9. Contexte et environnement de projet  Le contexte du projet prend en compte :  L’importance du projet dans l’organisation  Le rapport entre la stratégie de l’organisation et le projet  La relation entre le projet et les autres projets  Le rapport entre le projet et la plan de mise en œuvre sous-jacent  Les facteurs d’environnement interne ou externe influencent la planification du projet dans son ensemble et la réussite du projet.
  10. Formes d’organisation de projet  Influence, Pure, Matricielle
  11. Organisation d’influence ou fonctionnelle
  12. Organisation Matricielle
  13. Organisation Pure ou par Projet
  14. Communication et culture de projet  Selon la taille, la complexité du projet et les personnes concernées, lors du lancement du processus de gestion du projet, la communication peut être réalisée par :  Des entretiens particuliers  Des réunion de lancements  Des ateliers de démarrage de projet  Une combinaison des trois  Les cultures et les styles peuvent avoir une forte influence sur la capacité d’un projet à atteindre ses objectifs. Les normes culturelles comprennent une connaissance commune sur la façon d’approcher la réalisation du travail, les moyens considérés comme acceptables pour cette réalisation et les personnes dont l’influence va la faciliter.
  15. Objectif du projet  Les résultats attendus d’un projet doivent être clairement définis et de type SMART.  Les objectifs principaux sont directement liés au succès de l’entreprise.  Les objectifs complémentaires ne sont pas liés aux objectifs principaux du projet, mais peuvent contribuer à sa réussite.  Les non-objectifs précisent la portée et clarifient les limites du projet.
  16. Rôles et responsabilités  Cadres supérieurs  Responsables des utilisateurs  Comité directeur du projet  Responsable du projet  Gestionnaire du projet  Equipe de projet utilisateur  Responsable de la sécurité des SI  Assurance qualité  …
  17. Pratique de gestion de projet  La gestion de projet est la mise en pratique des connaissances, des habiletés, des outils et des techniques appliqués à une large gamme d’activités en vue d’atteindre un objectif défini, comme celui de satisfaire aux exigences déterminées de l’utilisateur et de respecter les échéances et le budget. Budget Livrables Durée
  18. Pratique de gestion de projet: Initiation  Le gestionnaire ou le responsable doit recueillir l’information nécessaire pour obtenir l’approbation du projet.  L’information sera souvent utilisée comme référence ou charte de projet pour déterminer les objectifs du projet, les intervenants dans le système à concevoir ainsi que le gestionnaire et le responsable du projet.  Le projet devient officiellement autorisé lorsque la charte du projet est approuvée.
  19. Pratique de gestion de projet: Planification  Le gestionnaire de projet doit déterminer :  Les diverses tâches qui doivent être effectuées pour créer le système d’application de gestion attendu  La séquence ou l’ordre d’exécution des tâches  La durée ou la fenêtre de temps de chaque tâche  La priorité de chacune des tâches  Les ressources liées aux TI qui sont disponibles ou nécessaires pour effectuer ces tâches  Le budget ou le coût de chacune des tâches  Les sources et moyens de financement
  20. Pratique de gestion de projet: Gestion générale  La gestion générale de projet se sert de techniques automatisées pour traiter les offres et les estimations de coûts en plus de surveiller les performance, de faire les prévisions et de présenter des rapports tout en proposant des mesures concrètes.  Documentation : Les outils de documentation automatisés gèrent la production, la validation et la mise à jour des documents relatifs aux programmes et aux systèmes  Bureautique : La bureautique diminue le travail du personnel relatif aux fonctions qui doivent être conformes aux politiques et effectue des fonctions de communication et de consignation lors de rencontre du personnel
  21. Pratique de gestion de projet: Contrôle  Gestion de la portée : Se fait à travers une structure de répartition du produit généralement dans une base de données de gestion des composantes.  Utilisation des ressources : Processus de dépense du budget du projet. Pour vérifier si les dépenses réelles correspondent aux dépenses prévues, l’utilisation des ressources doit être mesurée et rapportée.  Gestion du risque : consiste en cinq étapes exécutées à répétition pendant un projet (Répertorier les risques, évaluer les risques, atténuer les risques, découvrir les risques, réviser et
  22. Pratique de gestion de projet: Fermeture  Un projet doit avoir une durée de vie limitée pour qu’à un moment donné il soit fermé et que le système, nouveau ou modifié, soit remis aux utilisateurs ou au personnel de soutien du système.  Quelques activités de clôture de projet :  Transmission de la documentation  Tenir un registre des leçons apprises  Evaluer la qualité du travail, de l’équipe et les liens avec les environnements pertinents
  23. Développement des applications d’affaires  Nouvelle occasion reliée à un nouveau processus opérationnel ou à un processus existant  Problème relié à un processus opérationnel existant  Nouvelle occasion permettant à l’entreprise de tirer profit de la technologie  Problème avec la technologie actuelle
  24. Modèle Vérification et Validation Exigences de Test l’utilisateur d’acceptation Exigences Test de fonctionnelles système Conception Test architecturale d’intégration Conception Test unitaire détaillé Code
  25. Approche traditionnelle du CDS 3A- 4A- Conception Développement 1- 2- 5- 6- Post Faisabilité Exigences Implantation Implantation 3B- 4B- Sélection Configuration
  26. Etude de faisabilité  Définir un échéancier pour l’implantation de la solution requise  Déterminer une solution de rechange optimale basée sur le risque  Déterminer si un système existant peut corriger la situation avec de légères modifications ou sans modifications  Déterminer si le produit d’un fournisseur propose une solution au problème  Déterminer le coût approximatif de concevoir le système afin de corriger le problème  Déterminer si la solution convient à la stratégie de l’entreprise
  27. Définition des exigences  Identifier et consulter les partenaires pour déterminer leurs exigences  Analyser les exigences pour détecter et corriger les conflits et déterminer les priorités  Identifier les limites du système et la façon dont le système doit interagir avec son environnement  Convertir les exigences de l’utilisateur en exigences de système  Enregistrer les exigences fans un format structuré  Vérifier que les exigences sont complètes; constantes, limpides, vérifiables, modifiables, testables et traçables
  28. Conception  Elaboration d’organigrammes et de modèles entité relation pour illustrer comment l’information circulera à travers le système  Définition de l’utilisation des techniques structurées de conception qui montrent diverses relations de haut niveau jusqu’en détails  Description des entrants et des sortants telles que la conception des écrans et les rapports  Définition des étapes de traitement et des règles de calculs lors du traitement des besoins fonctionnels  Définition de la conception des fichiers de données ou des fichiers des systèmes de bases de données  Préparation des spécifications du programme pour les divers types d’exigences ou de critères d’information définis  Élaboration des plans de tests pour les divers niveaux de test  Elaboration des plans de conversion des données pour convertir les données et les procédures manuelles du vieux système au nouveau système
  29. Développement  Codage et rédaction de documents reliés au programme et au système  Débogage et test des programmes conçus  Conception de programmes visant à convertir les données du vieux système afin qu’elles puissent être utilisées dans le nouveau système  Création de procédures utilisateurs pour gérer la transition vers le nouveau système  Formation d’utilisateurs sélectionnés sur le nouveau système puisque leur participation sera nécessaire  Assurance que les modifications sont documentées et appliquées convenablement et complètement au système
  30. Implantation  Mise en place des structures de soutien dans l’entreprise  Formation des utilisateurs finaux  Conversion des données du vieux système  Migration des données dans le nouveau système  Derniers tests d’acceptation
  31. Révision post implémentation  Evaluer la pertinence du système  Vérifier si le système respecte les exigences de l’utilisateur et les objectifs de l’entreprise  Vérifier si les contrôles d’accès ont été définis et implantés convenablement  Evaluer les mesures coûts-avantages et du retour sur investissement prévue  Rédiger les recommandations qui abordent les lacunes et les insuffisances du système  Elaborer un plan pour l’implantation des recommandations  Evaluer le processus de projet de conception:  Est-ce que les méthodologies, normes et techniques choisies ont été suivies ?  Est-ce que les techniques de gestion de projet appropriées ont été utilisées ?
  32. Système d’application d’affaires  Le commerce électronique  L’échange de documents informatisés  Le courrier électronique  Système d’intelligence artificielle  Système d’aide à la décision  Gestion de la relation clientèle  Autre systèmes d’application d’affaires
  33. Commerce Electronique  Modèles de commerce électronique  Relations entreprise à client  Relations entreprise à entreprise  Relations intra-entreprise  Relations entreprises-gouvernement  Relations clients-gouvernement  Relation d’échange
  34. Commerce Electronique  Architecture du commerce électronique  Langage XML  Modèle de composants( COM, EJB)  Environnement (.NET, ONE, JAVA)  Serveur d’applications (BEA, Websphere, Oracle AS, …)  Serveur de bases de données (Oracle, MySQL, SQL Server, …)
  35. Commerce Electronique  Risques du commerce électronique  Confidentialité  Intégrité  Disponibilité  Authentification et non-répudiation  Transfert de pouvoir aux clients
  36. Commerce Electronique  Audit du commerce électronique  Des mécanismes et procédures de sécurité  Processus d’identification  Signatures numériques  Procédures de contrôle des changements  Méthode de monitoring des brèches de sécurité  Organisation de la confidentialité  Mécanismes de protection des composants  Responsabilité partagée et comprise  Programme régulier d’audit
  37. Echange de Documents Informatisés  Exigences générales  Logiciel de base  Système d’application  EDI Traditionnel  Gestionnaire de télécommunication  Interface de délimiteur de fin de trame  Système d’application  EDI sur le Web
  38. Echange de Documents Informatisés  Risques et contrôles d’EDI  Autorisation des transactions  Perte de continuité des affaires  Corruption des applications d’EDI  Accès non autorisé aux transactions électroniques  Suppression ou manipulation des transactions avant ou après la mise en place de contrôles applicatifs  Perte ou duplication des transmissions d’EDI  Perte de confidentialité et mauvaise distribution des transactions d’EDI
  39. Echange de Documents Informatisés  Vérification d’EDI  Les procédés de chiffrement pour Internet  Vérification des transactions erronés, inhabituelles ou invalides  L’utilisation des contrôles totaux sur réception des transactions  L’utilisation des champs de contrôle au sein d’un message  L’utilisation des systèmes experts
  40. Courrier électronique  Composantes  Serveur de courrier électronique  Client de messagerie  Problème de sécurité liés au courriel  Failles dans la configuration du serveur  Informations sensibles transmises sans chiffrement  Virus et autres types de codes malveillants  Exposition légale suite à l’envoie d’une information inappropriée
  41. Système d’intelligence artificielle  Principes :  La connaissance est acquise et exploitée  Les buts sont déterminés et atteints  L’information est communiquée  La collaboration est fournie  Les concepts sont formés  Les langages sont développés
  42. Système d’intelligence artificielle  Domaines d’application de l’IA  Les systèmes experts  Les langages naturels et artificiels  Gestion du texte intelligent  Démonstration de théorèmes  Raisonnement abstrait  Reconnaissance de formes  Reconnaissance vocale  Résolution de problèmes  Traduction automatique de langue étrangères
  43. Système d’aide à la décision  Vise à résoudre les problèmes moins structurés et moins bien définis auxquels sont confrontés les cadres supérieurs  Combine l’utilisation de modèles ou de techniques d’analyse aux fonctions d’accès et d’extraction conventionnelles des données  Met l’accent sur la souplesse et l’adaptabilité pour composer avec les changements dans l’environnement et l’approche pour la prise de décision des utilisateurs.
  44. Gestion de la relation avec la clientèle  Se concentre sur l’information relative aux données transactionnelles, les préférences, les modèles d’achat, l’historique des contacts, les renseignements démographiques et les courants en matière de service à la clientèle plutôt que les produits.  La gestion opérationnelle vise à maximiser l’utilité de l’expérience du service à la clientèle tout en enregistrant des données utiles sur l’interaction du client.  La gestion analytique cherche à convertir les données que recueille l’organisation sur ses clients et sur ses interactions avec elle en données qui lui permettent de maximiser l’achalandage.
  45. Autres systèmes d’application d’affaires  Systèmes de terminaux de point de vente  Banque virtuelle  Finance électronique  Système de paiement  Systèmes intégrés de fabrication  Transfert électronique de fonds  Fichiers de clientèle intégré  Bureautique  Guichet automatique bancaire  Systèmes de traitement coopératifs  Réponse vocale automatique
  46. Audit du développement, de l’acquisition et de la maintenance des systèmes  Déterminer les principales composantes, objectifs et exigences afin d’identifier les sections qui requièrent des contrôles.  Déterminer et classer les risques  Identifier les contrôles permettant d’atténuer les risques et les expositions qui peuvent affecter le système  Evaluer les contrôles disponibles  Réviser la documentation et las livrables  Evaluer les normes et procédures de maintenance du système dans le but de s’assurer de leur exactitude  Analyser les résultats des tests  Identifier et tester les contrôles existants
  47. Remerciements  Pour IBT ( Institute of Business and Technology)  BP: 15441 Douala - Cameroun  Par Arsène Edmond NGATO, CISA, CISM, PMP, OCP 10g/11g  Téléphone- 99183886  Email- arsenengato@yahoo.fr  Sources : Manuel de préparation CISA 2012, 4 ème Edition du PMBoK, Divers articles téléchargés sur Internet.
  48. Question type examen  Pour aider à tester un système bancaire principal qu’elle est sur le point d’acheter, une entreprise a fourni au fournisseur des données sensibles de son système de production existant. La préoccupation PRINCIPALE d’un auditeur des SI serait que les données soient: A. épurées. B. complètes. C. représentatives. D. actuelles.
  49. Question type examen  Laquelle des mesures suivantes constitue la MEILLEURE mesure préventive pour atténuer les risques découlant d’un éventuel désastre naturel pour un système de TI ? A. Identifier les menaces naturelles. B. Choisir un emplacement sécuritaire pour les installations. C. Garder les systèmes critiques et les systèmes généraux dans des endroits distincts. D. Mettre à jour et entreposer les copies de secours hors site.
  50. Question type examen  En effectuant un examen de la réingénierie du processus opérationnel, le vérificateur des SI découvre qu’un contrôle préventif clé a été supprimé. Dans cette situation, le vérificateur des SI doit: A - informer la direction de sa découverte et déterminer si celle-ci est prête à accepter le risque matériel potentiel engendré par cette suppression. B - déterminer si un contrôle de détection a remplacer un contrôle préventif pendant le processus, et si ce n’est pas le cas, signaler la suppression du contrôle préventif. C – recommander que cette procédure et toute les procédures qui existaient avant que le processus soient remodelé fassent partie du nouveau processus. D – développer une approche de vérification continue pour surveiller les effets de la suppression du contrôle préventif.
  51. Question type examen  Au cours de quelle étape suivante de réingénierie du processus opérationnel l’équipe d’analyse comparative doit-elle visiter l’organisation partenaire? A. Observation B. Planification C. Analyse D. Adaptation
  52. Question type examen  Laquelle des lacunes suivantes serait considérée comme la PLUS sérieuse pour un logiciel de planification des ressources d’entreprise (ERP) utilisé par un banque ? A. Les contrôles d’accès n’ont pas été passés en revue. B. La documentation disponible est limitée. C. Des bandes de sauvegarde vieilles de deux ans n’ont pas été remplacées. D. Une copie de secours de la base de données est effectuée une fois par jour.
  53. Question type examen  Lorsqu’il vérifie la phase relative aux exigences de l’acquisition d’un logiciel, l’auditeur des SI doit: A. Évaluer la faisabilité de l’échéancier du projet. B. Évaluer les processus de qualité proposés par le fournisseur. C. S’assurer de l’acquisition du meilleur progiciel. D. Réviser l’exhaustivité des spécifications
  54. Question type examen  Une entreprise décide d’acquérir un progiciel au lieu de le concevoir. Dans une telle situation, les phases de conception et de développement classiques des systèmes seraient remplacées par: A. les phases de sélection et de configuration. B. les phases de faisabilités et d’exigences. C. les phases d’implantation et de test. D. rien; aucun remplacement n’est nécessaire.
  55. Question type examen  Les spécifications de l’utilisateur définies pour un projet réalisé par la méthode traditionnelle du cycle de développement des systèmes n’ont pas été respectées. Laquelle de ces phases doit examiner l’auditeur des SI pour découvrir ce qui a engendré cette situation? A. Assurance – qualité B. Exigences C. Développement D. Formation de l’utilisateur
  56. Question type examen  Lors de l’introduction d’une architecture client léger, lequel des risques suivants, en ce qui concerne les serveurs, est augmenté de façon significative ? A. L’intégrité B. La concurrence C. La confidentialité D. La disponibilité
  57. Question type examen  Laquelle des procédures suivantes doit être implantée pour aider à assurer l’exhaustivité des transactions entrantes par l’échange de documents informatisés (EDI)? A. Totaux de contrôle incorporés dans l’enregistrement complémentaire de chaque segment B. Un journal du nombre de messages reçus, vérifié périodiquement avec l’expéditeur de la transaction C. Une piste d’audit électronique pour la responsabilité et la poursuite D. Établir une correspondance entre les accusés de réception, des transactions reçues au journal des messages d’EDI envoyés

Notes de l'éditeur

  1. Le chapitre sur l’acquisition, la conception et l’implantation des systèmes d’information donne un aperçu des processus et méthodologies clés utilisés par les organisations lors de la création et de la modification d’éléments des systèmes d’applications et de l’infrastructure. L’objectif de ce domaine est de garantir que le candidat au titre de CISA comprend et peut fournir l’assurance que les pratiques en matière d’acquisition, de conception, de test et d’implantation des systèmes d’information respecteront les stratégies et objectifs de l’organisation. Ce domaine représente 19 % des questions de l’examen CISA (soit environ 38 questions).
  2. 1- La nature temporaire des projets implique un commencement et une fin déterminés. La fin est atteinte lorsque les résultats du projet sont satisfaits, ou lorsque le projet est arrêté parce que ses objectifs ne seront pas atteint ou ne peuvent pas l’être, ou lorsque le projet n’est plus utile. 2- Le management de projet est effectué en appliquant et en intégrant, de manière approprié, les processus de management de projet groupés logiquement dans les cinq groupes de processus (démarrage, planification, exécution, surveillance et maîtrise, et clôture). 3- Les responsables de la stratégie effectuent une étude approfondie et évaluent quels facteurs sont « admissibles » ou « gagnants », puis il comparent ces facteurs aux forces, aux faiblesses et aux compétences des services disponibles pour compléter et maintenir les systèmes
  3. 1- Comme les projets, les programmes ont un calendrier d’exécution plus précis, et des limites organisationnelles. Ce qui les différencie, c’est que les programmes sont plus complexes, qu’ils ont habituellement une durée de vie plus longue, un plus gros budget, qu’ils comportent des risques plus élevés et que leur nature même fait qu’ils sont d’une plus grande importance stratégique. Les programmes lié aux SI typique peut être, par exemple, la mise en œuvre d’un système de planification des ressources de l’organisation (PRO = ERP) à grande échelle comme SAP, comprenant des projets qui tiennent compte des infrastructures technologiques, des activités, de la réorganisation, de la restructuration des activités et de l’optimisation, la formation et le développement. Les Fusion Acquisition sont des exemples de programmes non liés au SI. 2- Pour faciliter l’autonomie des projets tout en tirant parti des synergies entre projets d’un programme, la mise en place d’une organisation dédiée du programme est nécessaire. Les rôles types au sein du programme sont le responsable de programme, le directeur de programme, l’équipe de programme et le bureau de programme.
  4. 1- A la différence de la gestion de programmes, où tous les projets concernés sont étroitement associés, ce n’est pas une exigence pour le dossier de projets. Les projets d’un programme font partie du dossier de projets de l’entreprise, tout comme les projets n’étant pas associés à un programme. 2- Une base de données du dossier de projets est obligatoire pour la gestion du dossier de projets. Elle doit comprendre les données des projets, comme le nom du responsable du projet, les calendriers, les objectifs, le type de projet, son état d’avancement, les coûts, etc. La gestion du dossier de projets nécessite la production de rapports particuliers au dossier de projets (graphique à barrs du dossier de projets, matrice des profits par rapport aux risques, graphe de progression du dossier de projet, etc…). Encore appelé gestion de portefeuille de projet
  5. En fonction de l’organisation, et souvent, de la taille de l’investissement, le développement d’un plan de mise en œuvre est soit la première étape dans un projet, soit le précurseur du commencement du projet. Si, à n’importe quelle étape, on croit que le plan de mise en œuvre n’est plus valable, à cause d’une augmentation des coûts ou d’une réduction de la rentabilité anticipée, le parrain du projet ou le comité directeur du projet doit alors décider si le projet doit se poursuivre. Dans un projet bien planifié, il y aura des moments de décision, appelés « point d’arrêt », où le plan de mise en œuvre sera officiellement révisé pour s’assurer qu’il est toujours valable. Si le plan de mise en œuvre change durant le cours du projet de TI, ce dernier doit être de nouveau approuvé par le processus d’approbation du service.
  6. Il existe aujourd’hui plusieurs approches de gestion de projet. Certaines se concentrent sur le développement de logiciels, d’autres ont une approche plus générale; certaines se concentre sur une perspective holistique et systémique, d’autres proposent un flux de travail très détaillé comprenant des modèles pour la création de documents. Parce qu'il y a d’importantes différences de portée, de contenu et de vocabulaire dans chacune de ces normes, le vérificateur doit se familiariser avec la norme utilisée avant de s’impliquer dans des projets spécifiques. Bien qu’il y ait des pour et des contres à chaque approche de gestion de projets, plusieurs éléments sont communs à toutes les méthodologies de gestion de projets
  7. La gestion de projet constitue un processus administratif de l’organisation axés sur les projets. Le processus de gestion de projet commence avec la charte du projet et se termine avec l’achèvement du projet.
  8. Comme il y a normalement plusieurs projets se déroulant en même temps, les relations entre ces projets doivent être examinées pour déterminer des objectifs communs pour l’organisation, déterminer et gérer les risques, et déterminer les relations entre les ressources. Une approche courante pour traiter ces questions consiste à établir une structure de gestion du dossier de projet et de gestion du programme. Les exemples de facteurs environnementaux de l’entreprise sont : la culture, la structure et les processus organisationnels Les normes gouvernementales ou d’industries applicables à l’organisation L’infrastructure Les ressources humaines existantes (les compétences, les disciplines et les connaissances telles que conception, développement, aspects légaux, établissement de contrats et les approvisionnements) L’administration du personnel Les systèmes d’autorisation de travaux de l’entreprise Les conditions du marché La tolérance aux risques des parties prenantes Le climat politique Les canaux de communication établis dans l’organisation Les bases de données commerciales (par exemple, les données d’estimation des coûts standards, les informations provenant d’études de risque dans l’industrie et les bases de données des risques) Les systèmes de gestion de l’information du projet (outil automatisé tel qu’un logiciel de planification, un système de management de la configuration, un système de collecte et de diffusion de l’information, ou des interfaces web avec d’autres systèmes automatisés en ligne)
  9. 1- Le directeur de projet a une fonction consultative sans avoir une autorité officielle de gestion. Il n’a que le droit de conseiller ses pairs et les membres de l’équipe quant aux activités à réaliser. 2- Le directeur de projet à une autorité officielle sur ceux qui prennent part au projet. Il s’agit souvent de fournir une aire de travail particulière à l’équipe projet, qui soit séparée de leur espace normal de bureau 3- Dans une organisation matricielle, l’autorité de gestion est partagée entre le directeur de projet et les chefs de service. Pour l’achèvement réussi du projet, on doit donner au chef de projet, qui n’est pas nécessairement membre du personnel des SI, l’autorité opérationnelle complète du projet, et on doit lui allouer les ressources appropriées, y compris des professionnels des SI et autre personnel des services utilisateurs. Des vérificateurs des SI peuvent faire partie de l’équipe du projet à titre d’experts en contrôle. Ils peuvent également fournir un bilan indépendant et objectif pour garantir que le niveau de participation (d’engagement) des groupes responsable est approprié. Dans pareils cas, les vérificateurs des SI n’effectuent pas un audit, mais ils participent au projet à titre consultatif, il pourrait devenir inadmissibles à effectuer des audits de l’application lorsque celle-ci sera fonctionnelle.
  10. Les entretiens particuliers et les ateliers de démarrage de projet aident à faciliter une communication bilatérale entre les membres de l’équipe du projet et le directeur de projet. Le directeur de projet peut tenir une réunion de lancement pour informer l’équipe de ce qui doit être fait pour le projet. Une des méthodes préférentielles garantissant une communication ouverte et claire au sein de l’équipe de projet est la tenue d’un atelier de démarrage de projet pour obtenir la coopération de tous les membres de l’équipe et la participation de tous les intervenants. Ceci contribue à créer une vision d’ensemble commune du projet et à communiquer la culture du projet dès le début. En tant que système social in dépendant, chaque projet à sa propre culture qui définit ses normes et règles d’engagement. La culture du projet ne peut être décrite, mais elle se manifeste dans les techniques appliquées de gestion de projet, y compris la planification de projet, les formes de communication, etc … Les dynamiques de la culture de projet fournissent une compréhension commune de ce qui est perçu comme souhaitable et de ce qui sert d’orientation à l’équipe. L’établissement d’un énoncé de mission du projet, d’un nom et d’un logo pour le projet, de règles de réunion ou d’un bureau, d’un intranet de projet, de règles de réunion et d’un protocole de communication pour l’équipe du projet, ainsi que d’activités sociales liées au projet, sont autant de méthodes de création d’une culture de projet.
  11. Stratégiques, Mesurables, Atteignables, Réalistes et Temporels (temps opportun). Exemple : réorganisation des domaines d’activité dans le cadre d’un projet de développement de logiciel.
  12. 1- démontrent leur engagement envers le projet et approuvent les ressources nécessaires pour le terminer. Cet engagement des cadres supérieurs aide à assurer la participation des personnes nécessaires à l’exécution du projet. 2- Prennent en charge la responsabilité du projet et du système qui en découle, associent des représentants qualifiés à l’équipe, puis participe activement à la nouvelle conception du processus de gestion, à la définition des exigences du système, au développement des scénarios de test, aux essais d’acceptation et à la formation des utilisateurs. Ils doivent réviser et approuver les biens livrables liés au systèmes. 3- Fournit les directives générales et assure la représentation appropriée des principales parties prenantes dans la conclusion du projet. Essentiellement, le comité directeur est responsable de tous les bien livrables, des coûts et des calendriers de projet. Le comité doit être formé d’un haut représentant de chaque secteur d’activité qui sera touché de façon importante par le nouveau système proposé ou par les modifications au système. Chaque membre doit pouvoir prendre des décisions relatives à la conception du système qui touchera son service respectif. 4- Fournit les fonds pour le projet et travaille en étroite collaboration avec le gestionnaire du projet en vue de définir les facteurs déterminant de réussite et les paramètres d’évaluation de la réussite du projet. 5- Assure la gestion et la direction du projet au quotidien, garantit que les activités du projet restent conformes à l’orientation générale, assure la représentation adéquate des services touchés, assure que le projet est conforme aux normes locales, assure que les biens livrables satisfont aux attentes des intervenants clés, résout les conflit interservices, puis surveille et contrôle les coûts et les échéanciers du projet. 6- Effectue les tâches assignées, accomplit le travail selon les normes locales et conseille le gestionnaire de projet relativement aux changements actuels et futurs du plan d’exécution du projet. 7- Garantit que les contrôles du système et les processus de soutien procurent un niveau de protection efficace en fonction de la classification des données déterminée en accord avec les politiques et procédures de sécurité de l’entreprise. 8- Vérifie les résultats et les biens livrables au cours de l’exécution des phases et à la fin de chaque phase, puis confirme sa conformité aux exigences. L’objectifs est de s’assurer de la qualité du projet, en déterminant si le personnel affecté au projet suit le cycle de vie de développement des logiciels de l’organisation, d’offrir des conseils relatifs aux dérogations et de proposer des recommandations visant à améliorer les processus ou augmenter les points de contrôles lorsque surviennent des changements
  13. Techniques d’estimation de la tailles et mesures : Estimation de la taille du logiciel : méthodes de détermination de la taille physique relative du logiciel d’application à développer Analyse des points fonctionnels : méthodes d’estimation de la complexité du développement de grandes applications de gestion Estimation du cout du logiciel : découle de l’estimation de la taille du logiciel et prend en compte les facteurs de coût suivant le langage de code source, les contraintes de temps d’exécution, les contraintes de stockage principal, les contraintes de stockage de données, l’accès à l’ordinateur, la machine cible utilisée pour le développement, l’environnement de sécurité, les qualifications du personnel, … Planification et élaboration du délai d’exécution Méthode du chemin critique, diagramme de GANTT, Méthode de la programmation optimale (Réseau PERT)
  14. Comprennent les gestion de la portée ainsi que l’utilisation des ressources et des risques 2 Technique de l’estimation de la valeur acquise
  15. Le processus d’implantation des applications de gestion, aussi appelé cycle de développement de systèmes, s’amorce lorsqu’une étude de faisabilité d’une application est déclenchée en raison d’une ou de plusieurs des situations suivantes : Les projets d’applications doivent être déclenchés à l’aide de procédures ou d’activités bien définies à l’intérieur d’un processus défini visant à faire part des besoins de l’entreprise à la direction. Ces procédures nécessitent souvent une documentation détaillée qui identifie le besoin ou le problème et qui mentionne la solution privilégiée ainsi que les avantages possibles pour l’entreprise. Il faut identifier tous les facteurs internes et/ou externes touchés par le problème ainsi que l’impact pour l’entreprise.
  16. Tout projet de conception d’un logiciel comporte le risque de ne pas respecter toutes les exigences. Des problèmes provoqués par des erreurs de traduction surviennent lors de la définition initiale des exigences pour les produits temporaires. Ce modèle de chute et ses variantes nécessitent habituellement une approche de la vérification du cycle de vie, qui s’assure que les erreurs potentielles sont corrigées rapidement et non pas uniquement au cours des derniers tests d’acceptation. Le modèle V met aussi l’accent sur la relation entre les phases de développement et les niveaux de tests. Le test le plus granulaire (le test unitaire) se fait immédiatement après l’écriture des programmes. Des tests sont effectués en conformité avec ce modèle afin de valider la conception organique. Les tests de système se rapportent aux spécifications architecturales du système, alors que les tests d’acceptation de l’utilisateur final se rapportent aux exigences.
  17. Aussi appelée technique de chute, cette approche est la plus vielle et la plus répandue pour concevoir des applications. Elle est basée sur une approche systématique et séquentielle de la conception de logiciels (principalement des applications de gestion) qui commence par une étude de faisabilité et évolue ensuite vers la définition des exigences, la conception, le développement, l’implantation et la post implantation.
  18. Le but de l’étude de faisabilité est d’analyser les avantages et les solutions pour l’aspect du problème identifié. Comprend l’élaboration d’une analyse de cas, qui dicte les avantages stratégiques d’implanter le système en termes de gains de productivité ou en évitement de coûts futurs. Elle détermine et quantifie les économies du nouveau système et évalue un calendrier de remboursement pour les couts encourus lors de l’implantation du système, ou elle montre le retour sur investissement projeté. Des avantages intangibles tels que l’amélioration du moral peuvent aussi être identifiés. Cependant les avantages doivent être quantifiés autant que possible. L’étude de faisabilité englobe les éléments suivants : Les facteurs qui ont un impact sur la décision de concevoir ou d’acquérir un système incluent : La date à laquelle le système doit être fonctionnel Le coût de conception par opposition au cout d’achat Les ressources, le personnel (disponibilité de l’ensemble des compétences) et le matériel requis pour concevoir un système ou implanter la solution d’un fournisseur Les caractéristiques de la licence (renouvellement annuel ou perpétuel) et les couts d’entretien Une interface permettant l’échange d’information entre les autres systèmes et le système acheté La compatibilité avec les plans d’affaires stratégiques La compatibilité avec l’infrastructure TI de l’entreprise Les exigences futures probables pour apporter des modifications aux fonctionnalités offertes par le systèmes.
  19. La définition des exigences se préoccupe d’identifier et de spécifier les besoins fonctionnels et non fonctionnel du système choisi pour la conception lors de l’étude de faisabilité. Les exigences comprennent la description de ce qu’un système doit faire, de la manière dont les utilisateurs interagiront avec le système, des conditions sous lesquelles le système fonctionnera et des critères d’information (efficacité, efficience, confidentialité, intégrité, disponibilité, conformité fiabilité) que le système doit respecter. Pour ce faire, vous devez :
  20. En se basant sur la conception préliminaire générale et les exigences des utilisateurs définies dans la phase de définition des exigences, l’équipe de programmation et d’analyste peut effectuer une conception détaillée. Il est question ici de définir l’architecture du système, décrire les plans généraux du système, détailler et décomposer ensuite le système en ses parties constituantes comme les modules et les composantes. Les activités de cette phases sont les suivantes :
  21. La phase de développement utilise la conception détaillée, élaborée à l’étape précédente, pour commencer à code ce qui amène le système un peu plus près du produit final. Les responsabilité au cours de cette phase incombent surtout aux programmeurs et aux analystes de systèmes qui construisent le système. Les activités clés effectuées dans un environnement de test et de développement incluent :
  22. Lors de la phase d’implantation, le fonctionnement réel du nouveau SI est établi et testé. Les tests finaux d’acceptation de l’utilisateur sont effectués.
  23. A la suite de l’implantation réussie d’un nouveau système ou d’un système considérablement modifié, il est avantageux de vérifier que le système a été bien conçu et que les contrôles approprié ont été incorporés dans le système. Une révision post implantation doit atteindre les objectifs suivants :
  24. Afin de concevoir des programmes d’audit efficaces, l’auditeur des SI doit avoir une compréhension claire du système d’application qui est vérifié. Nous fournissons dans cette partie, une description de quelques types de systèmes et de leurs procédés connexes. Un grand nombre de fonctions financières et opérationnelles sont informatisées dans le but d’améliorer et d’augmenter la fiabilité des informations. Ces applications peuvent être classiques (comme le grand livre général, les comptes créditeurs et la paie) ou spécifiques à l’industrie (comme les prêts bancaires, les compensations de commerce et la planification des exigences matérielles). Etant donné leurs caractères uniques, les systèmes d’application informatiques ajoutent de la complexité aux efforts d’audit.
  25. Le commerce électronique consiste en l’achat de biens et services en ligne, normalement au moyen d’Internet. Typiquement, un site Web fera de la publicité pour des biens et des services, et l’acheteur remplira un formulaire sur le site Web pour choisir les articles qu’il veut acheter et fournira les détails concernant la livraison et le paiement ou les services bancaires, comme les ordres de virement et le paiement. Le terme commerce électronique comprend les achats et les ventes en ligne tout comme d’autres aspects d’affaires en ligne, par exemple l’assistance à la clientèle ou les relations entre les entreprises.
  26. Un grand nombre de choix doivent être faits pour déterminer une architecture appropriée de commerce électronique. Au départ deux tiers, mais aujourd’hui n tiers.
  27. Le commerce électronique, comme tout autre forme de commerce, dépend de l’existence d’un niveau de confiance entre deux parties. Par exemple, Internet présente un défi entre l’acheteur et le vendeur, semblable à celui auquel un détaillant par catalogue ou un détaillant par publipostage fait face. Les défis prouvent à l’acheteur que le vendeur est bien celui qu’il prétend être, prouvent à l’acheteur que ces renseignements personnels comme son numéros de cartes de crédit (et autres renseignements d’identification personnelle) demeurent confidentiels et que le vendeur ne peut pas contester une transaction valide. Par conséquent, quelques-uns des éléments à risque les plus importants sont : 1- Fournir des renseignements personnels et de nature sensible à un fournisseur inconnus peut conduire à un vol d’information suite à un achat. De plus, le media Internet est un réseau de diffusion générale, ce qui signifie que peu importe ce qui s’y trouve, on le diffuse sur des chemins de grande étendue et qui sont essentiellement non contrôlés. 2-Les données, tant en transit que stockées, sont susceptibles d’être modifiées ou supprimées de façon non autorisée (ie un piratage informatique pourrait subvenir ou encore le système de commerce électronique lui-même pourrait éprouver des problèmes de conception ou de configuration). 3- Internet permet de faire des affaires 24/24 et 7/7. Du coup, il est primordial que le site de commerce électronique possède un haut niveau de disponibilité, puisque toute défaillance du système devient immédiatement visible pour les clients ou les partenaires commerciaux. 4- Les parties impliquées dans une transaction électronique doivent avoir une relation commerciale connue et à laquelle ils font confiance, qui exige qu’ils prouvent leur identité respective avant d’exécuter la transaction afin de prévenir des attaques provenant du centre. Une fois l’identité vérifiée, il faut définir une façon de s’assurer que les parties qui transigent ne peuvent pas nier que la transaction a été contractée, ni les termes sous lesquels elle a été complétée. 5- Pour éviter de perdre leur avantage concurrentiel de faire des affaires en ligne, les entreprises doivent améliorer leurs services, se différencier de la compétition et bâtir une valeur ajoutée en ciblant le contenu basé sur le comportement du client analysé, et en permettant le contact direct avec le personnel par la technologie de messagerie instantanée et d’autres moyens.
  28. Lors de la révision de l’exactitude des contrats dans les applications de commerce électronique, l’audit et les professionnels de contrôle doivent évaluer l’utilisation applicable des points suivants : 1- Coupe feux d’internet, Infrastructure à Clé Publique, Chiffrement, gestion des certificats et mot de passe
  29. L’EDI remplace d’échange de documents papier traditionnels comme les bons d’achat, les factures ou les calendriers de mise en production du matériel. 1- Le système d’EDI demande des logiciels de communication, des logiciels de traduction ainsi que l’accès aux normes. Le logiciel de base d’un EDI comprend la transmission, la traduction et le stockage des transactions entreprises par le traitement d’application, ou destinés pour ce dernier. L’EDI est aussi un système d’application dans lequel les fonctions qu’il exécute sont basées sur les besoins et les activités de l’organisation. 2-Le déplacement des données par le biais d’un processus de transmission par lots en passant par le processus EDI traditionnel implique généralement trois fonctions dans chaque système des partenaires commerciaux : Le processus de transmission et réception des documents électroniques entre les partenaires commerciaux par le biais des lignes commutées, de réseau public à commutation, de ligne spécialisées multiples ou un réseau à valeur ajouté. Une fonction d’interface qui manipule et dirige les données entre le système d’application et le gestionnaire des communications. Les programmes qui traitent les données envoyés au partenaire commercial, ou reçues de ce partenaire commercial. 3-Les techniques d’échanges commerciaux d’EDI sur Internet visent à améliorer l’échange entre les partenaires commerciaux, les fournisseurs et les clients en réduisant les frontières qui limitent la façon dont ils interagissent et font des affaires entre eux.
  30. 1-L’interaction entre les parties est électronique, aucune authentification n’est faite. Les données informatiques peuvent paraître semblables, peu importe la source, et ne comprennent pas de facteurs humain distinctif ou de signature humaine.
  31. L’auditeur des SI doit évaluer l’EDI pour s’assurer que toutes les transactions entrantes d’EDI sont reçues et traduites avec précision, transmises à une application et traitées seulement une fois. Afin d’accomplir ce but, l’auditeur des SI doit réviser les points suivants :
  32. Le courrier électronique est la fonction la plus utilisée d’Internet ou des réseaux locaux. Au niveau le plus primaire, le processus de courriel peut être divisé en deux composantes principales. 1- Les hôtes qui livrent, font suivre et stockent le courrier 2- Interagissent avec les utilisateurs et permettent aux utilisateurs de lire, composer, envoyer et stocker des courriels.
  33. Les systèmes experts sont une branche de l’IA et exécutent une tâche spécifique et sont couramment utilisés dans certaines industrie. Le système expert permet à l’utilisateur de spécifier certaines hypothèses ou formules de base pour analyser des évènements arbitraires. Une conclusion est tirée à partir de l’information utilisée comme donnée d’entrée. L’utilisation des systèmes experts dans une organisation comporte plusieurs avantages : La collecte du savoir et l’expérience des personnes avant qu’elles ne quittent l’organisation Le partage du savoir et de l’expérience dans des domaines où l’expertise est limitée La facilitation de prise de décision efficace et cohérente L’amélioration de la productivité et du rendement du personnel L’automatisation des tâches hautement répétitives Le fonctionnement dans des environnements où un expert humain n’est pas disponible
  34. Il s’agit d’un système interactif qui donne à l’utilisateur un accès à des modèles décisionnels et à des données provenant de plusieurs sources dans le but de l’aider dans les tâches liées au processus décisionnels semi-structuré. Un système d’aide à la décision peut présenter l’information sous forme graphique et peut inclure un système expert ou une intelligence artificielle. De plus il peut être destiné aux cadres supérieurs de l’entreprise ou à un autre groupe de spécialistes de l’information. Voici quelques caractéristiques d’un système d’aide à la décision :
  35. On a recours au modèle de gestion analytique pour trouver des moyens d’amener les clients à dépenser davantage ou à partager le portefeuille de client, pour diriger les clients vers les produits à marges de profit plus élevées, pour diriger les clients vers des prestations de services moins couteuses, pour augmenter les taux de réussite en commercialisation et pour établir des prix.
  36. 1- Les TPV permettent la saisie de données au moment et à l’endroit de la transaction. Les méthodes de paiement les plus communes pour faire fonctionner un STPV sont les cartes de crédit et de débit, qui sont associés à des comptes bancaires. 2- Ensembles de services électroniques et à distances offert par les banques aux clients (Transfert électronique de fond, guichet automatique bancaire, …) 3 -
  37. Les tâches de l’auditeur des SI quant au développement, à l’acquisition et à la maintenance des systèmes peuvent se dérouler une fois le projet terminé ou, moins fréquemment, pendant le projet comme tel. Les tâches comprennent :
  38. A- Les données de test doivent être épurées pour empêcher que les données confidentielles se retrouvent dans les mains de personnes non autorisées.
  39. B – choisir un emplacement sécuritaire pour les installations est la meilleure mesure préventive, car les emplacements qui accueilleront des systèmes, de l’information ou des actifs de TI sensibles doivent être choisis de manière à minimiser l’exposition au risque comme les incendies, les inondations , les dégâts causés par l’eau, les agents corrosifs ou les radiations électromagnétiques produites à l’extérieur. Identifier les menaces naturelles fait partie de l’analyse des risques et est la première étape pour déterminer un emplacement sécuritaire, mais ce n’est pas la meilleure mesure préventive. Garder les systèmes critiques et généraux dans des endroits distincts est la meilleure pratique pour la sûreté des installations et des équipements. Des copies de sauvegarde conservées hors site peuvent atténuer le risque, mais ne constitue pas une mesure préventive.
  40. A – les gestionnaires doivent être informés immédiatement pour déterminer s’ils souhaitent accepter le risque matériel potentiel de ne pas avoir de mesure de contrôle préventive en place. L’existence d’une mesure de contrôle de détection remplaçant une mesure de contrôle de prévention augmente habituellement les risques qu’un problème matériel puisse survenir. Souvent, au cours d’un BPR, plusieurs mesures de contrôle sans valeur ajoutée seront éliminées. Il s’agit d’une bonne chose, sauf si les risques financiers et d’entreprise augmentent. L’auditeurs des SI pourrait souhaiter assurer un suivi du nouveau processus ou recommander que les gestionnaires en assurent le suivi, mais cela doit être fait seulement après que ces derniers aient été informés et qu’ils aient accepté le risque de ne pas avoir de mesure de contrôle préventive en place.
  41. A -Pendant l’étape d’observation, l’équipe recueille les données et visite le partenaire d’analyse comparative. Lors de l’étape de planification, l’équipe identifie les processus essentiels pour l’analyse comparative. L’étape d’analyse implique le résumé et l’interprétation des données recueillies et l’analyse des écarts entre le processus de l’organisation et le processus de son partenaire. Au cours de l’étape d’adaptation, l’équipe à besoin de traduire les résultats en quelques principes généraux et de les transformer en stratégies, puis en plans d’action.
  42. A - Ne pas passer en revue les contrôles d’accès dans une organisation financière pourrait avoir des conséquences graves. Le manque de documentation n’est pas aussi grave qu’omettre de passer en revue les contrôles d’accès. Il n’est peut-être même pas possible de récupérer les données veilles de deux ans. Il peut être acceptable pour l’entreprise de n’enregistrer qu’une copie de sauvegarde par jour, tout dépendant du volume de transactions.
  43. D – l’objectif de l’étape des exigences est de spécifier la fonctionnalité du système proposé ; pour cette raison, l’auditeur des SI doit se concentrer sur l’intégralité des spécifications. La décision d’acheter un ensemble d’un fournisseur vient une fois les exigences complétées. Les choix B et C sont donc incorrectes. Le choix A est incorrect parce qu’un calendrier de projet ne se trouve habituellement pas dans un document présentant les exigences.
  44. A – L’achat d’ensembles devenant de plus en plus chose commune, la conception et la mise en œuvre du cycle de vie traditionnel sont devenues remplaçables par les phases de sélection et de configuration. Une demande de soumission pour le fournisseur des ensembles de systèmes est émise et évaluée selon les critères prédéfinis de sélection, avant qu’une décision soit prise concernant l’achat du logiciel. Celui-ci est par la suite configuré pour répondre aux exigences de l’organisation. Les autres étapes, par exemple l’étude de faisabilité, la définition des exigences, l’implantation et la post- implantation, demeurent inchangées.
  45. C - De toute évidence, la gestion de projet a échoué relativement à la configuration ou la vérification des mesures de contrôle pour les logiciels ou les modules logiciels en développement qui se conforment aux spécifications mentionnées par les utilisateurs. L’assurance de la qualité met l’accent sur les aspects formels du développement de logiciels, tels que la conformité aux normes de programmation ou à une méthodologie de développement spécifique. Les questions fonctionnalité en termes de facilité d’utilisation sont hors de portée et font, dans ce cas, partie de la phase de développement. Echouer par rapport aux spécifications de l’utilisateur implique que l’ingénierie des exigences a été effectuée pour décrire les demandes des utilisateurs. Dans le cas contraire, il n’y aurait pas de base de référence de spécifications à comparer. En fonction de l’approche sélectionnée ( cascade traditionnelle, RAD? etc), ces écarts peuvent survenir pendant la formation de l’utilisateur ou les tests d’acceptation, peu importe lequel survient d’abord.
  46. D -Le principal changement lord de l’utilisation d’une architecture client léger est de rendre les serveurs essentiels pour l’opération; par conséquent, la probabilité que l’un d’eux cesse de fonctionner augmente et, par conséquent, le risque de disponibilité augmente également (option D). Parce que les autres éléments n’ont pas besoin d’être modifiés, les autres risques suggérés n’augmentent pas ( choix A, B, et C)
  47. A – les totaux de contrôle, élaborés dans l’enregistrement complémentaire de chaque segment sont la seule option qui assurera que toute les transactions individuelles envoyées sont reçues en entier. Les autres options fournissent des preuves , mais leurs résultats sont soit incomplets , soit inopportuns.
Publicité