Développement d'un système d'information comptable: modules d'entreprise, de base de données et d'interface
Développement d'un système d'information comptable: modules d'entreprise, de base de données et d'interface!
Un certain nombre de progiciels de comptabilité offrant une variété de fonctionnalités sont disponibles. Ils coûtent beaucoup moins cher que ce que coûterait un logiciel de comptabilité personnalisé. Cependant, ces progiciels n’offrent que la structure des systèmes d’information comptable. Tout au plus, ils réduisent les efforts de programmation des systèmes d’information comptable.
Courtoisie d'image: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg
La mise au point de systèmes d’information comptable va bien au-delà du logiciel d’affichage au grand livre et de création de rapports. Cela implique également la mise en place de procédures de saisie et de distribution des données, ainsi que l’analyse des informations comptables.
Le développement d’un système d’information comptable est expliqué en faisant particulièrement référence aux exigences d’une entreprise de taille moyenne à grande. Cependant, ces étapes seraient communes à la plupart des autres systèmes d’information d’une entreprise.
1. Module d'entreprise:
Le module entreprise de développement de systèmes d’information implique l’identification des entités de base et leurs interrelations, l’identification des activités de base et le regroupement de ces activités dans des sous-systèmes. Ensuite, les priorités sont définies sur la base d’une analyse coûts-avantages pour l’entreprise.
Identifier les entités:
Il existe un grand nombre d’entités dans une entreprise et la liste est aussi variée que les activités. Cependant, à ce stade, la principale préoccupation est d'identifier les entités larges, chacune d'entre elles contenant un groupe d'entités élémentaires. Kerner 5 indique six entités de base dans une entreprise.
Ce sont des clients, des produits, des vendeurs, du personnel, des installations et de l'argent. Dans un système d'information comptable, il existe trois entités de base, à savoir les transactions, le compte et la période de traitement. Les relations entre ces entités peuvent être exprimées à l'aide des diagrammes ER, comme indiqué dans la Fig. 8.2.
Les transactions doivent être de différents types, telles que recettes, paiements, ventes, achats, acquisitions d’actifs ou remboursement de passifs, etc., chacune d’elles pouvant être qualifiée d’entité de niveau inférieur. De même, les comptes peuvent être de différents types, tels que les actifs, les passifs, les produits et les charges.
Chacune de ces têtes peut avoir des entités de niveau inférieur telles que des actifs immobilisés et des actifs courants. Ces entités peuvent encore être divisées en entités de niveau inférieur, telles que terrains et bâtiments, installations et machines, etc. Cependant, à ce stade, les entités étendues doivent être identifiées. Les détails sont élaborés au moment de la conception des bases de données.
Les entités sont identifiées à la lumière de et en vue de définir la portée et la focalisation du système d’information. Par exemple, si le système d’information est considéré comme un système d’information stratégique, les entités globales doivent être identifiées à la lumière des orientations stratégiques que l’entreprise entend donner à ses activités à l’aide du système d’information.
Ces axes pourraient être la réduction des coûts, le service client, la différenciation des produits et les alliances stratégiques. Les entités de base dans un tel cas seraient les clients, les canaux, les entreprises concurrentes, les produits, etc.
Analyse d'activité:
Un autre aspect important du module d'entreprise est l'identification des activités associées aux entités. Ces activités sont largement identifiées sous la forme de relations dans les diagrammes ER. Cependant, les détails sont obtenus à l'aide de l'analyse d'activité. La structure organisationnelle existante est une source importante d’informations sur les activités générales entreprises par l’entreprise.
Toutefois, afin de développer des systèmes d’information indépendants de la structure organisationnelle actuelle, il est essentiel de baser l’analyse des activités sur les entités de base déjà identifiées ci-dessus. Le prochain niveau d’analyse des activités implique l’identification des activités du cycle de vie. Dans le cas où les «transactions» constituent l'une des entités de base d'un système d'information comptable, il existe quatre grandes activités de cycle de vie, à savoir:
1. Cycle de vie des achats
2. Cycle de vie de la production
3. Cycle de vie des revenus
4. Cycle de vie des investissements
De même, la période de traitement comporte deux activités de base du cycle de vie, à savoir:
une. Planification et contrôle du cycle de vie
b. Cycle de vie des rapports internes et externes
Ces activités du cycle de vie sont des activités continues et sont effectuées de manière continue. Chacune de ces activités peut être liée séquentiellement à d'autres activités. Le troisième niveau d'analyse des activités implique la scission des activités du cycle de vie en fonctions.
Par exemple, chaque type de transaction doit être initié et reconnu; ensuite, les données relatives à la transaction doivent être saisies, codées pour une classification future, classées, résumées et rapportées. Ces fonctions doivent être effectuées différemment pour différents types de transactions. Le processus de définition des fonctions se concentre uniquement sur les activités qui créent, mettent à jour ou utilisent des informations dans la base de données de l'entreprise.
À ce niveau d’analyse d’activité, les activités sont autonomes, ont des événements ou des nœuds de début et de fin clairement définis et une personne ou un groupe de personnes identifiable responsable de l’exécution de la fonction.
Ces fonctions peuvent ensuite être divisées en sous-fonctions jusqu'à ce qu'elles soient suffisamment spécifiques pour définir le module des programmes informatiques. La scission des activités du cycle de vie en fonctions et sous-fonctions aide à identifier les fonctions répétées dans plusieurs activités du cycle de vie.
Par exemple, la fonction de classification des données saisies peut être réalisée dans les cycles de vie des achats et du marketing. Une telle analyse des activités aide à identifier les possibilités d’améliorer la conception existante en:
1. éliminer les fonctions redondantes
2. combiner les fonctions dupliquées
3. simplifier et améliorer les méthodes de traitement
La redondance peut être identifiée par une analyse minutieuse des activités. Les activités susceptibles d'offrir des possibilités d'amélioration du traitement comprennent les activités suivantes:
une. Qui sont effectuées ailleurs aussi
b. Cela peut être combiné avec d'autres activités
c. Cela peut aussi être traité par une autre personne
ré. Cela peut être effectué à une autre étape du cycle de vie qui n’ajoute aucune valeur au produit ou au service du système d’information.
Une mise en garde est que tous les licenciements ne sont pas mauvais. En fait, une redondance ou une duplication peut être laissée intentionnellement dans le système. Cela peut être fait pour améliorer les performances et la fiabilité du système.
Par exemple, une partie de la duplication peut être nécessaire pour garantir la simplicité des procédures et améliorer la vitesse de traitement. L'élimination de la redondance peut aboutir à «mettre tous les œufs dans le même panier» et donc affecter la fiabilité. Le risque d’implications imprévues et de faibles rendements de la nouvelle méthode ou procédure proposée est un autre facteur qui mérite d’être examiné avant que des modifications ne soient proposées dans le système d’information.
Regroupement des activités dans des sous-systèmes:
Une fois les activités définies en utilisant l’approche descendante adoptée ci-dessus, elles sont regroupées pour former des sous-systèmes. Une décision importante à prendre à ce stade concerne la base de regroupement. Il peut ne pas y avoir un seul critère objectif pour décider à quel sous-système appartient une activité.
La structure organisationnelle actuelle peut fournir l’une des bases du regroupement d’activités. Cependant, la structure organisationnelle actuelle peut subir des changements et l’utilité du système d’information peut être perdue.
Pour regrouper les activités dans un sous-système, nous prenons l’aide de la théorie de l’organisation. L’une des caractéristiques essentielles de toute bonne structure d’organisation est qu’elle vise à faciliter la coordination des activités.
Un système de communication efficace est essentiel pour une meilleure coordination. Il est donc essentiel de regrouper les activités de manière à faciliter la communication au sein du groupe et à minimiser le besoin de communication entre groupes.
Pour représenter et documenter le regroupement d'activités dans des sous-systèmes, des diagrammes structurels ou des schémas fonctionnels hiérarchiques sont utilisés. La figure 8.3 présente un organigramme illustrant les composantes du cycle des revenus.
Des tableaux de structure similaires peuvent être préparés pour d'autres groupes d'activités et, finalement, ces sous-systèmes sont intégrés les uns aux autres, fournissant les éléments de base d'un système d'information comptable.
Les sous-systèmes ainsi identifiés par regroupement d'activités sont de sérieux prétendants au statut d'entités de la structure organisationnelle. L’avantage de la méthode de regroupement des activités pour le regroupement d’activités est qu’il repose sur des fonctions et des ressources, et non sur des régions géographiques.
Un tel regroupement sur la base de fonctions assure l’homogénéité des membres du groupe de personnes associé à chacun des sous-systèmes. L'impact de l'organisation du système d'information sur la structure organisationnelle n'est pas rare.
L’introduction de systèmes d’information s’est souvent accompagnée de modifications des structures organisationnelles, du fait que les nouveaux systèmes d’information modifient la façon dont les personnes travaillent dans une organisation.
Il est donc d’autant plus important que les concepteurs de systèmes d’information travaillent en étroite collaboration avec les responsables du développement de l’organisation tout en regroupant les activités en clusters et en sous-systèmes. Cela garantit non seulement que la nouvelle structure est plus pragmatique, mais également plus acceptable pour les gens. Dans de tels cas, la transition d'un ancien système à un autre est moins pénible et moins coûteuse.
Fixer des priorités:
Une fois que les sous-systèmes ont été identifiés et intégrés dans leur ensemble, les priorités doivent être déterminées entre les divers sous-systèmes et fonctionnalités de chaque système. Le système d’information nécessiterait un engagement de ressources financières.
En outre, le nouveau système peut entraîner des coûts implicites en termes de changements nécessaires dans le processus d'exploitation. Il est donc essentiel de peser le pour et le contre de chaque sous-système et sous-système avant leur conception et leur mise en œuvre.
Chaque sous-système est évalué sur la base de critères d’évaluation bien définis, définis en termes de facteurs de succès critiques (CSF). Ces facteurs ont déjà été identifiés à la section 8.2.
L’autre méthode consiste, en brainstorming, dans laquelle les personnes concernées de l’organisation se retrouvent pour identifier les facteurs qui méritent d’être pris en compte dans la détermination des priorités. La libre circulation des idées est encouragée dès la première étape.
Le principe sous-jacent, ici, est qu'aucune idée n'est idiote ou dénuée de pertinence à ce stade. Au cours de la deuxième étape, le processus d'élimination commence et après les discussions, les suggestions sont finalisées.
Une fois la liste des facteurs terminée, des poids relatifs sont attribués et une fonction de critère est définie pour évaluer chaque composant du système d'information comptable proposé.
2. Module de base de données:
Le système d'information comptable traite un grand volume de données. La gestion des données est donc l’une des considérations majeures de son développement. Il existe deux approches de base pour la conception des données, à savoir:
une. L’approche traditionnelle, axée sur les applications, et
b. L'approche base de données.
Approche traditionnelle:
L'approche traditionnelle de la conception des données est axée sur les applications en ce sens que pour chaque application, un ensemble séparé de fichiers de données est généré selon ses besoins. En d'autres termes, les fichiers de données sont dédiés à une application donnée et sont en quelque sorte "possédés" par l'application.
Par exemple, une application comptes clients doit avoir le fichier de données de base client, un fichier de transaction de vente et un reçu du fichier de transaction du client. Ces fichiers de données ne sont utilisés que pour l'application comptes clients.
Cette approche convient aux petits systèmes d’information comptable en raison de sa simplicité. Cependant, à mesure que le système d’information se développe en termes de volume de données et de complexité d’analyse, il pose également certains problèmes.
Le problème fondamental de l’approche traditionnelle est que les programmes d’application dépendent des fichiers de données qu’ils utilisent et manipulent. En conséquence, toute modification du fichier de données (en termes d’ajout ou de suppression d’élément de données) nécessite des modifications dans tous les programmes utilisant le fichier de données.
Cette dépendance aux données décourage les modifications dans les fichiers de données, ce qui entraîne une inflexibilité. En l'absence de tout outil permettant d'exécuter des activités de gestion de données de type courant sur les données, ces fonctions doivent être incluses dans les programmes utilisant le fichier de données. Cela complique le programme. Un autre problème concerne la réponse à la requête ad hoc.
Pour un type de requête inattendu, des programmes spéciaux doivent être écrits. De tels programmes spéciaux prennent du temps à se développer et n’ont qu’une utilisation ponctuelle et sont donc coûteux. Il y a beaucoup de duplication dans l'enregistrement des éléments de données.
Par exemple, les éléments de données tels que le nom du client, le numéro de facture, le prix, etc. peuvent être inclus dans les fichiers de transaction pour l'application de traitement de la commande client, ainsi que pour l'application comptes clients. Cela provoque la redondance dans les données.
La redondance des données entraîne une utilisation inefficace des supports de stockage. Cela affecte également la qualité des données car la mise à jour d'un élément de données donné peut ne pas avoir lieu dans tous les fichiers où cet élément de données est stocké.
Approche de la base de données:
L'approche moderne de la conception des données est l'approche de la base de données. Cette approche repose sur l'hypothèse que plusieurs applications nécessitent des ensembles de données ayant beaucoup en commun. Il est donc préférable d’avoir un référentiel commun de données qui réponde aux exigences de chaque application du système d’information.
Le référentiel commun s'appelle la base de données et est géré par un système de gestion appelé Système de gestion de base de données (SGBD). Le SGBD est un logiciel spécialement conçu pour gérer les données des bases de données en fonction des demandes des programmes d'application, ainsi que de celles provenant directement des utilisateurs. La conception de l'environnement de base de données est illustrée à l'aide de la Fig. 8.5.
L'approche base de données prend en charge les problèmes de l'approche applications. Il garantit l'indépendance des données car le SGBD prend en charge le flux de données de la base de données aux programmes d'application. L'application utilisateur n'a pas besoin de se préoccuper de l'emplacement des données dans la base de données. Un dictionnaire de données est mis à jour et les données peuvent être appelées à l'aide des mots spécifiés dans le dictionnaire de données.
L’approche par la base de données réduit également la taille et la complexité des programmes d’application car le type habituel d’opérations de traitement de données, tel que le tri, est effectué par le SGBD. Le SGBD est également utilisé pour répondre aux besoins des requêtes ad hoc. Le SGBD utilise le langage SQL (Structured Query Language) comme langage de communication entre l'utilisateur et la base de données.
La langue est très simple et assez proche de l'anglais. Cela garantit que l'utilisateur peut obtenir des informations de la base de données à tout moment. La quantité de formation requise par les gestionnaires pour effectuer des requêtes ponctuelles est minimale et quelques heures de formation peuvent fournir les compétences élémentaires nécessaires à l'utilisation de la langue. Peut-être que l'avantage le plus important de l'approche par base de données est la réduction de la redondance dans les bases de données.
Il existe de nombreux modèles couramment utilisés dans la conception de bases de données. Cependant, l'approche moderne consiste à suivre le modèle ER de la conception de la base de données. Cette approche est une approche descendante et les diagrammes ER dessinés précédemment dans le module Entreprise deviennent le point de départ.
Pour chaque entité et relation, les attributs sont identifiés et documentés dans les diagrammes ER étendu (diagrammes EER). Dans un système d'information comptable, le EER peut être établi pour chaque entité (transaction et comptes) et la relation (effet) pour les comptes de transaction est indiquée dans le diagramme ER. Par exemple, pour une transaction de vente, des attributs peuvent être spécifiés et documentés, comme illustré à la Fig. 8.6.
Ces attributs deviennent les éléments de données (champs) d'un enregistrement dans le fichier de données de chaque entité (dans ce cas, le fichier de transaction de vente). De même, pour d'autres entités et relations, de tels diagrammes ER étendu (EER) sont dessinés.
Une fois ces attributs identifiés, il est probable que certains attributs seront communs dans différentes cartes EER. Pour éviter la duplication de tels attributs communs, une normalisation des données est entreprise.
3. Module d'interface:
Un module d'interface définit les sources des éléments de données et les formats des écrans d'entrée / sortie et de dialogue à utiliser dans le système. Il définit également les formats de rapport et les écrans de navigation d’une partie des systèmes d’information à l’autre.
En d'autres termes, le module est chargé de définir l'interface entre l'utilisateur et la machine. L'importance du module d'interface a augmenté en raison de la communication accrue entre l'utilisateur et les systèmes d'information.
La saisie de données et la requête de données sont devenues interactives. Dans de nombreux cas, les formulaires de saisie sont éliminés du processus et la saisie des données a lieu directement. Les exigences changeantes des requêtes de données rendent de nombreux formulaires de rapport trop rigides. Les écrans de rapport interactifs offrent une plus grande flexibilité dans l'interrogation des données et permettent aux formats de rapport définis par l'utilisateur pour la visualisation et l'impression.
Écrans de saisie:
Les écrans de saisie sont définis à la lumière du processus naturel de l’activité commerciale. Par conséquent, ils dépendent principalement des formulaires utilisés pour enregistrer manuellement les données lors de leur première réception par l'entreprise. Ces formulaires, dans un système d’information comptable, peuvent inclure une facture, un bon de commande, une commande client, une note de service, etc.
Ainsi, dans le module d'interface, les formulaires sont également revus; Les écrans repensés et de saisie sont définis à la lumière des formulaires utilisés par l'entreprise. Dans un système d'information comptable, il faut être plus prudent en ce qui concerne la conception des écrans.
Une amélioration mineure de l'écran de saisie qui enregistre la saisie de données peut entraîner des économies substantielles car le nombre de fois où l'écran de saisie de données est utilisé est très grand. Les facteurs suivants peuvent être pris en compte lors de la conception d’un écran de saisie:
(a) Correspondance avec les formulaires:
Le format de l'écran de saisie doit correspondre aux formulaires de saisie. Parfois, il est avantageux d’adopter le même format que celui utilisé par le formulaire de saisie. Dans la mesure du possible, même la couleur de l'arrière-plan de l'écran peut correspondre à la couleur du formulaire de saisie.
b) interactif:
L'écran de saisie doit être interactif. Il convient de signaler les erreurs dans la saisie des données au moment de la saisie et de permettre les corrections. Chaque élément de données doit avoir une condition de validation des données et toute violation de cette condition doit être automatiquement mise en évidence au moment de la saisie des données.
Par exemple, un écran de saisie des données pour la saisie de la facture doit signaler une erreur dans la saisie de la date si la date est invalide. La date peut être invalide car elle se situe en dehors de la période comptable ou si le mois entré est supérieur à douze.
c) Cohérence:
Les écrans de saisie doivent être cohérents dans la définition des termes et de l'emplacement de certains types courants d'éléments de données. Cela aide à réduire le temps d’entraînement car cela améliore la familiarité; Par exemple, la date de transaction peut toujours être placée dans le coin droit de chaque document de transaction.
d) simplicité:
L'une des caractéristiques de base d'un bon écran de saisie est la simplicité. Trop de sections en surbrillance, des valeurs ou des attributs clignotants, ou trop de cases et de soulignements ne font qu'ajouter à la complexité et à la confusion. Parfois, les signaux sonores sont utilisés pour signaler des erreurs de saisie de données. Ces signaux sonores doivent être utilisés de manière judicieuse et doivent généralement être évités.
e) Flexibilité:
L'écran de saisie doit pouvoir être modifié. Il devrait permettre aux utilisateurs d’apporter des modifications en termes d’ajout, de suppression et de déplacement d’éléments de données. La procédure de modification doit être simple. De nos jours, les générateurs d’écran disponibles auprès de divers fabricants de logiciels offrent des fonctionnalités telles que le glisser-déposer / supprimer / déposer tout élément de données de l’écran en utilisant un périphérique de pointage ordinaire comme la souris.
(f) Fait sur mesure:
Les écrans doivent être personnalisés pour chaque catégorie d’utilisateur. Cela réduirait indûment les procédures de démarrage et d’entrée trop longues.
Écrans de rapport:
Les rapports peuvent être préparés pour une analyse ultérieure par un autre programme informatique ou par l'utilisateur lui-même. Les données destinées à être traitées par des programmes informatiques, telles que des tableurs, des progiciels statistiques, des traitements de texte, sont conservées dans des fichiers de données.
Il est préférable de les mettre au format de données standard afin de pouvoir y accéder facilement. Les rapports destinés aux utilisateurs sont normalement conservés sous forme de texte, de tableaux et de graphiques. Des efforts doivent être faits pour que les rapports soient établis et communiqués en temps voulu, avec précision, clarté et à moindre coût.
Écrans de dialogue:
Les écrans de dialogue sont ceux utilisés pour identifier et exécuter les tâches dans le système d’information. Ils définissent ce qui peut être fait à l'aide du système d'information, comment naviguer d'une tâche / procédure à une autre et comment effectuer diverses tâches autorisées par le système d'information.
Ces écrans doivent être simples et sans ambiguïté. La simplicité peut être introduite en fournissant une interface utilisateur graphique (GUI) et en limitant le nombre d’éléments de menu sur un seul écran. La procédure de navigation d’un menu à l’autre doit être simple, bien ordonnée et facile à suivre. Il convient également de signaler une erreur dans l’exercice des options et d’être prompt à corriger la procédure.
Outils CASE pour la conception d'écran:
Divers outils CASE sont disponibles pour la conception de formulaires, d'écrans et de rapports. Ces outils ont l'avantage d'offrir un environnement de conception flexible et simple à comprendre, même pour un nouvel utilisateur.
Étant donné que ces outils disposent d'installations de prototypage d'écran, il est possible d'impliquer davantage les utilisateurs dans le processus de conception d'écran. Bien entendu, de tels outils permettent des changements rapides et améliorent la productivité des programmeurs en générant des codes pour la mise en œuvre finale. Cela réduit le temps de développement.
Une fois que les formulaires, les écrans d’entrée / de sortie et les écrans de dialogue sont prêts, ils doivent être testés et modifiés en conséquence. Les formulaires et les écrans conçus à l'aide des outils CASE peuvent être facilement modifiés. Par conséquent, des efforts doivent être faits pour améliorer l'acceptabilité du système en testant et en modifiant correctement les formulaires et les écrans.
4. Module d'applications:
Ce module étend les sous-systèmes déjà identifiés dans le module d'entreprise. Pour chaque sous-système identifié dans l'organigramme, des procédures de traitement détaillées sont définies dans ce module.
En d’autres termes, le module d’application concerne principalement les processus impliqués dans la conversion des données d’entrée en valeurs qui doivent faire partie des rapports définis dans le module d’interface. On peut noter que seuls ces processus doivent être définis pour
(a) Modifier les valeurs dans les bases de données, ou
(b) Cela ne fait pas partie de la base de données mais est requis dans les rapports définis dans le module d'interface.
Les valeurs qui existent déjà dans la base de données sont accessibles à l’aide du langage de requête du SGBD, conformément à la demande des utilisateurs qui ne développent pas de programmes à cette fin. Ainsi, la tâche du module d’application est réduite par le travail déjà effectué dans la conception de la base de données et la conception de l’écran.
Diagramme de flux de données:
Le rôle du responsable dans ce module consiste essentiellement à identifier la procédure de traitement de base. Les algorithmes détaillés sont généralement définis et documentés par des professionnels des systèmes d’information, bien sûr, avec l’aide active du responsable.
L'outil utilisé pour exprimer les processus à exécuter pour convertir les données d'entrée en sortie est le diagramme de flux de données (DFD). Il décrit le flux de données. Il définit ce qui doit être fait et ignore comment et comment cela se faisait plus tôt. Cette approche permet de modifier le système et les faiblesses du système existant peuvent être éliminées grâce à cette approche.
Symboles DFD:
Quatre symboles de base sont utilisés dans les DFD. Elles sont:
(i) Terminator:
Terminator est une source externe de flux de données ou un puits de données externe. Il s'agit d'une entité externe ou d'un objet tel qu'un client, un fournisseur, des actionnaires, etc. Les terminateurs étant des entités externes, la communication entre les terminateurs est exclue du système. Le terminateur est symbolisé par un rectangle (généralement ombré) et l'étiquette est placée dans le rectangle.
ii) flux de données:
Le flux de données transporte une série d'éléments de données concernant l'événement initié par le terminateur. Il est symbolisé par une flèche en DFD et la direction du flux est indiquée par la direction de la flèche. Les flèches sont généralement étiquetées, sauf si elles sont dirigées vers ou à partir de fichiers de données. Comme indiqué précédemment, les flux de données entre deux terminateurs ne sont pas inclus dans la DFD et ne peuvent donc pas circuler directement entre deux terminateurs.
(iii) processus:
Process transforme les données entrantes pour les rediriger vers le magasin de données ou le terminateur. Il est symbolisé par un rectangle aux coins arrondis ou un cercle. Il est marqué avec un verbe, bien sûr.
iv) Magasin de données:
Les fichiers sont les magasins de données dans les systèmes d’information et sont représentés dans les DFD sous forme de rectangles ouverts. Généralement, ils correspondent aux tables des bases de données. Une vue partielle du diagramme de flux de données pour le traitement des commandes client est présentée à la Fig. 8.7.
Il convient de noter que certains symboles supplémentaires et variations mineures dans les symboles représentant diverses composantes de la DFD sont également utilisés. Les symboles ci-dessus sont les plus couramment utilisés et sont conformes à la convention graphique suggérée par Gane et Sarson.
Plusieurs fois, un manager trouve que dessiner avec DFD est une expérience très difficile et frustrante. Chaque fois que l’on dessine un DFD, l’un ou l’autre aspect du flux de données est ignoré. Heureusement, les outils CASE disponibles disposent de fonctionnalités permettant de créer et de modifier des DFD. Toutefois, il est conseillé aux débutants de suivre les étapes suivantes pour résoudre ce problème:
(a) Identifiez tous les flux de données d'entrée et les flux de données de sortie séparément, ainsi que les terminateurs, en plaçant les flux de données d'entrée à gauche et les flux de données en sortie à droite.
(b) Étiquetez les terminateurs en utilisant les noms nominaux ou adjectifs du flux de données.
(c) Identifiez les processus en aval des flux de données d'entrée et en arrière des flux de données en sortie jusqu'à ce qu'ils se rencontrent au milieu.
(d) Étiquetez les processus en utilisant des noms de verbe.
Un gestionnaire doit être prêt à redessiner le DFD, car plusieurs fois, les flux de données ne deviennent clairs pour le gestionnaire qu’après le dessin DFD. La participation des utilisateurs à ce stade est très utile, non seulement pour réduire les efforts du gestionnaire, mais également pour améliorer le DFD.
Test de DFD:
Il est suggéré de bien tester le DFD avant de le finaliser. Voici quelques-unes des erreurs courantes dans la conception DFD:
une. L'étiquette de terminaison peut être le nom d'une personne ou d'une entreprise au lieu de classe. Par exemple, un terminateur peut être étiqueté M / s. BR Ltd. au lieu de fournisseur unique. Une autre erreur pourrait être que l’opérateur soit mis en place comme terminateur au lieu de l’entité externe directement associée au flux de données.
b. Les données peuvent passer directement d'un terminateur à un autre.
c. Aucun flux de données ne peut être indiqué vers ou depuis un processus.
ré. Le flux de données est indiqué d'un terminateur à un magasin de données (fichier) ou d'un fichier à un terminateur, ou entre deux fichiers sans traitement.
e. Les processus sont étiquetés comme des objets, tels qu'une facture ou un nom tel qu'un commis aux réservations.
Une fois que les DFD sont établis pour chaque sous-système, les détails du traitement futur peuvent être définis et décrits en anglais structuré (psedo-codes). Ces psedo-codes sont ensuite utilisés pour coder les applications. Le rôle du gestionnaire dans ce processus se limite à aider le professionnel des systèmes d’information à identifier et à comprendre les algorithmes impliqués dans le traitement.
5. Module de mise en œuvre:
Ce module concerne principalement les tests du système, la formation des utilisateurs et l’installation du système.
Test du système:
Les tests de différents modules sont effectués à différentes étapes du processus de développement. La règle d’or à garder à l’esprit lors du test est que le test doit être effectué dans le but d’identifier les causes potentielles de l’échec du système. L’objectif ne doit pas être de prouver que le système fonctionnera conformément aux spécifications de conception. Le test du système consiste à chercher des réponses à deux questions fondamentales:
1. Le système d’information répond-il aux besoins en information de l’entreprise? Le processus qui cherche à répondre à cette question est qualifié de processus de validation par les professionnels des systèmes d’information.
2. Le système d'information fonctionne-t-il correctement? Le processus de vérification cherche à répondre à cette question.
Étant donné que la nature et le degré de gravité des erreurs diffèrent à différentes étapes du développement du système, différents tests sont administrés pour différents modules et pour le système dans son ensemble.
Test de l'unité:
Les tests utilisés au niveau du module peuvent être appelés tests unitaires. Ces tests sont effectués pour détecter les erreurs dans les interfaces, les bases de données, les opérations arithmétiques et la logique de contrôle. Elles sont effectuées en exécutant un module du système d’information sur des données de test spécialement conçues pour vérifier si le système:
une. Accepte un type de données incorrect (p. Ex. Accepte une valeur numérique pour le nom);
b. Accepte les données de plage valides (p. Ex. Accepte la date avec un mois supérieur à 12);
c. Provoque un saut incorrect d'une procédure à une autre.
Test du système:
Les tests unitaires étant réalisés de manière isolée, il est essentiel de procéder aux tests d'intégration pour vérifier si ces unités fonctionnent correctement en tant que groupe. En raison des différences de nature des erreurs, différentes stratégies de test doivent être suivies pour vérifier la validité et vérifier le système. Fertucksuggests propose trois stratégies pour tester le système d’information:
a) Essai de boîte transparente:
Dans cette stratégie, les tests sont conçus pour établir si les procédures suivies pour le traitement correspondent aux exigences de l'application. Cela peut être réalisé avec l'aide de collègues professionnels du système d'information, qui n'étaient pas directement associés au stade du développement.
Alternativement, une méthode de visite structurée peut être utilisée. Dans cette méthode, un groupe de personnes examine les procédures, commence par examiner les pièces sujettes aux erreurs et identifie les corrections à apporter. Ensuite, les membres du groupe évaluent la sortie que le système offrira pour un type d'entrée donné et testeront si la sortie du système est correcte ou non.
b) Essai de la boîte noire:
Dans cette stratégie, le système est testé pour les données non valides ou pouvant provoquer une erreur dans le fonctionnement du système. La sortie est vérifiée pour déterminer si une erreur s'est produite. Par exemple, les données peuvent contenir une valeur négative pour la quantité commandée ou une valeur fractionnelle pour une variable ne pouvant prendre qu'une valeur entière.
c) essais de case à cocher:
Cette stratégie suppose qu'il n'est jamais possible de mettre en place un système d'information totalement exempt d'erreurs. Ainsi, après tous les tests et les modifications, il est nécessaire d'estimer le nombre d'erreurs restant dans le système. Pour estimer ce nombre, quelques erreurs peuvent être délibérément introduites dans le système. Ensuite, les tests sont à nouveau effectués pour détecter les erreurs.
La proportion d'erreurs introduites détectées est considérée comme une estimation de la proportion d'erreurs réelles détectées lors des tests précédents. Ainsi, si 90% des erreurs introduites ont été détectées lors du test de case à cocher alors qu'un total de 450 erreurs ont été détectées à l'origine lors du test de la case vide et du test de la boîte noire, cela signifie que 50 erreurs réelles restent non détectées dans le système.
Installation:
L’installation consiste à remplacer l’ancien système par un nouveau. De manière générale, il existe quatre approches d'installation. L'installation «à froid» est effectuée lorsque l'ancien système est immédiatement arrêté et est remplacé par un nouveau système.
Une telle installation présente l'avantage d'un ajustement psychologique plus rapide du fait que le nouveau système doit être utilisé. Cependant, une telle approche peut ne pas être appropriée si les anciennes données du système précédent sont utiles ou si le nouveau système rencontre des problèmes. Pour l’installation de systèmes d’information comptable, cette approche n’a pas été jugée acceptable. Les approches alternatives incluent:
a) Installation pilote:
Un système peut être installé pour être utilisé uniquement par un groupe d'utilisateurs représentatif sélectionné qui teste le système en l'utilisant réellement. D'autres utilisateurs continuent à utiliser l'ancien système. Lorsque les problèmes du système sont résolus, d'autres utilisateurs commencent également à utiliser le système. Cette approche n’est également pas très répandue dans les systèmes d’information comptable car la base de données comptable complète doit être mise à jour avant de pouvoir être utilisée par les utilisateurs.
Les besoins d'informations de l'utilisateur dépassent les limites du département et des divisions dans l'organigramme. Cependant, cette approche peut être utilisée pour des entités comptables complètes telles qu'une succursale, un bureau régional, etc. Ainsi, un système d'information comptable peut être utilisé par certaines succursales. Une fois qu'elles se sont avérées sans erreur, elles peuvent également être utilisées par d'autres branches.
b) Installation progressive:
Sous cette approche, l'installation se fait par étapes. Ces étapes sont des composants indépendants du système d'information. Ainsi, le cycle de vie des revenus d’un système d’information comptable peut être d’abord installé et d’autres cycles de vie peuvent se succéder. Cette approche aide à se concentrer sur une partie sélectionnée du système. Cela contribue à améliorer l'acceptabilité du système par les utilisateurs, car cela leur permet de faire face facilement aux changements.
(c) Installation parallèle:
L’installation en parallèle signifie l’exécution simultanée de l’ancien et du nouveau système pendant un certain temps, jusqu’à preuve de l’utilité du nouveau système. Cette méthode est la plus répandue dans les systèmes d’information comptable car c’est la plus sûre des autres méthodes. La seule difficulté, ici, est le coût de la course en parallèle et la tendance à prolonger la période de course en parallèle par ceux qui résistent au changement.
Examen après mise en œuvre:
Chaque système doit être examiné une fois l’implémentation terminée. Un tel examen aide non seulement à identifier les faiblesses du système, mais prépare également un ordre du jour en vue d’une modification pour l’avenir. C'est en fait un processus d'apprentissage. Un audit du système peut également être effectué pour examiner le succès du système en termes de coût, de calendrier de livraison, d’exhaustivité et de qualité.
