introduction

La thèse à l'étude a été rédigée sur la base de Donetsk OJSC Donetsk Manufactory pour le magasin Cleonelly.

L'une des principales activités de Donetsk Manufactory OJSC produit une large gamme de vêtements, principalement des peignoirs, des draps et des serviettes. En outre, l'entreprise produit des fils de coton teints pour le tissage et le tricotage.

Le développement des technologies de l'information automatisées va de pair avec l'émergence de nouveaux types de moyens techniques de traitement et de transmission de l'information, l'amélioration des formes d'organisation d'utilisation des ordinateurs, la saturation de l'infrastructure avec de nouveaux moyens de communication. Le développement des relations de marché a conduit à l'émergence de nouveaux types d'activité entrepreneuriale et, tout d'abord, à la création d'entreprises engagées dans le commerce de l'information, au développement des technologies de l'information, à leur amélioration, à la diffusion de composants de technologies de l'information automatisées, en particulier des produits logiciels qui automatisent les processus d'information et de calcul. Ils comprennent également les équipements informatiques, les moyens de communication, les équipements de bureau et des types spécifiques de services - information, services techniques et de conseil, formation, etc. Cela a contribué à la diffusion rapide et à l'utilisation efficace des technologies de l'information dans les processus de gestion et de production, presque à leur utilisation généralisée et à leur grande diversité.

Les entreprises engagées dans la conception et le développement d'appareils à des fins diverses utilisent actuellement largement divers moyens de conception assistée par ordinateur - CAO (CAO) et de surveillance des processus de production - ACS (SCADA / DCS). Cependant, pour les appareils de notre propre conception, il est nécessaire de développer nos propres moyens de surveiller leurs performances et d'analyser la qualité des produits.

Le processus technologique de comptabilisation des produits dans un entrepôt dans un magasin Cleanelly comprend l'étape de tenue des registres des produits vendus.

Le but de ce projet de diplôme est la mise en place d'un poste de travail automatisé (AWP) qui permet la comptabilisation des produits dans un entrepôt de magasin.

Pour atteindre l'objectif ci-dessus, il est nécessaire de résoudre les tâches suivantes:

¾ analyser les processus d'affaires du magasin;

¾ explorer les flux d'informations survenant au stade de la livraison d'un produit en cours de développement;

¾ développer des modèles de données conceptuels et logiques;

¾ développer un logiciel de poste de travail automatisé pour les produits comptables

¾ évaluer l'efficacité économique du système d'information.

1 Développement des exigences logicielles

1.1 Analyse des solutions existantes

Actuellement, il existe un large éventail d'entreprises qui combinent à la fois le développement direct de produits et le développement de systèmes de contrôle pour ces produits. De tels systèmes sont développés par des sociétés bien connues telles que 1: C Enterprise et Zvezda. Ces systèmes contrôlent et comptabilisent les matériaux et traitent les informations reçues.

"1C: Enterprise" est un système de solutions appliquées construit sur les mêmes principes et sur une plate-forme technologique unique. Le gestionnaire peut choisir une solution qui répond aux besoins actuels de l'entreprise et se développera à mesure que l'entreprise grandit ou que les tâches d'automatisation se développent.

Le système logiciel 1C: Enterprise est conçu pour résoudre un large éventail de tâches d'automatisation de la comptabilité et de la gestion auxquelles sont confrontées les entreprises modernes en développement dynamique. Solution des problèmes urgents de comptabilité et de gestion La composition des programmes du système 1C: Enterprise est centrée sur les besoins réels des entreprises. L'entreprise "1C" produit des solutions logicielles en série conçues pour automatiser les tâches de comptabilité et de gestion typiques des entreprises. Une particularité des solutions de l'édition 1C est une étude approfondie de la composition des fonctionnalités incluses dans les solutions standard. La société "1C" analyse l'expérience des utilisateurs utilisant les programmes du système "1C: Enterprise" et surveille l'évolution de leurs besoins.

Les principaux avantages de mon système Wholesale Base incluent le coût relativement bas de mise en œuvre de ce système, ainsi qu'un certain nombre d'autres avantages:

¾ Fiabilité des applications créées. Le progiciel (PC) doit être résistant non seulement aux erreurs de l'utilisateur, mais également aux pannes du système de communication.

¾ Facilité d'utilisation de l'interface;

¾ Haut niveau de sécurité du système, ce qui implique non seulement un contrôle sur la disponibilité de certaines ressources du système et la sécurité de l'information à tous les stades de l'exploitation, mais également le suivi des actions effectuées avec un haut degré de fiabilité.

1.2 Analyse de domaine

La particularité de l'analyse du domaine est qu'elle permet de voir l'ensemble des opérations de l'organisation.

CASE est conçu pour analyser et réorganiser les processus métier. – Tous les outils de premier niveau de Fusion Process Modeler (BPwin) prenant en charge les méthodologies IDEF0 (modèle fonctionnel), DFD (Dataflow Diagram) et IDEF3 (Workflow Diagram). BPwin est un logiciel puissant permettant de créer des modèles pour analyser, documenter et planifier les changements dans des processus métier complexes. BPwin propose un outil de collecte de toutes les informations pertinentes sur le fonctionnement de l'entreprise et de représentation graphique de ces informations sous la forme d'un modèle cohérent et cohérent.

En termes de fonctionnalité du système. Dans le cadre de la méthodologie IDEF0 (Integration Definition for Function Modeling), un processus métier est représenté comme un ensemble d'éléments de travail qui interagissent les uns avec les autres, et les informations, les ressources humaines et de production consommées par chaque travail sont affichées. Le modèle fonctionnel est destiné à décrire les processus métier existants dans l'entreprise (le modèle dit AS-IS) et l'état idéal des choses – à quoi aspirer (modèle TO-BE). La méthodologie IDEF0 prescrit la construction d'un système hiérarchique de diagrammes, i.e. descriptions uniques des fragments du système. Tout d'abord, une description du système dans son ensemble et de son interaction avec le monde extérieur (diagramme de contexte) est effectuée, après quoi une décomposition fonctionnelle est effectuée – le système est divisé en sous-systèmes et chaque système est décrit séparément (diagrammes de décomposition). Ensuite, chaque sous-système est décomposé en plus petits et ainsi de suite pour atteindre le niveau de détail souhaité.

Si dans le processus de modélisation, il est nécessaire de mettre en évidence les aspects spécifiques de la technologie d'entreprise, BPwin vous permet de passer à n'importe quelle branche du modèle en notation DFD ou IDEF3. Les diagrammes DFD (Data Flow Diagramming) peuvent compléter ce qui est déjà reflété dans le modèle IDEF3, car ils décrivent les flux de données, vous permettant de suivre la manière dont les informations sont échangées entre les fonctions métier au sein du système. Dans le même temps, les diagrammes DFD ignorent les interactions entre les fonctions métier.

En termes de séquence de travail effectué. Et une image encore plus précise peut être obtenue en complétant le modèle avec des diagrammes IDEF3. Cette méthode attire l'attention sur l'ordre dans lequel les événements sont exécutés. Des éléments de logique sont inclus dans IDEF3, qui vous permet de modéliser et d'analyser des scénarios alternatifs pour le développement d'un processus métier.

Pour prendre en compte les processus métier dans l'entrepôt d'un magasin, seules deux méthodologies IDEF0 et DFD doivent être utilisées. Le processus de modélisation d'un système dans IDEF0 commence par définir le contexte, c'est-à-dire le niveau de description le plus abstrait du système ou des processus métier en général.

Modèle IDEF0 ... Pour étudier les processus métiers «Formation d'une commande fournisseur», «Réception de marchandises», «Sortie de marchandises», considérez les schémas qui se présentent sous forme de diagramme IDEF0. Le système IDEF0 est présenté comme un ensemble d'activités ou de fonctions en interaction.

La méthodologie IDEF0 est basée sur quatre concepts principaux.

Le premier est le concept bloc fonctionnel (Boîte d'activités) ... Un bloc fonctionnel est représenté graphiquement sous la forme d'un rectangle et personnifie une fonction spécifique dans le cadre du système considéré

Chacun des quatre côtés d'un bloc fonctionnel a sa propre signification (rôle), tandis que:

Le côté supérieur est Control;

Le côté gauche est réglé sur "Entrée";

Le côté droit est réglé sur Sortie;

L'inconvénient est «mécanisme».

La deuxième "baleine" de la méthodologie IDEF0 est le concept d'un arc d'interface (Arrow). L'affichage graphique de l'arc d'interface est une flèche unidirectionnelle. Chaque arc d'interface doit avoir son propre nom (étiquette de flèche). À l'aide d'arcs d'interface, divers objets sont affichés qui, à un degré ou à un autre, déterminent les processus en cours dans le système. Dans ce cas, les flèches, en fonction de la face du rectangle de travail dans laquelle elles entrent ou de la face qu'elles quittent, sont divisées en:

Les flèches d'entrée (incluses dans le côté gauche du bloc fonctionnel) - représentent des données ou des objets qui sont modifiés pendant l'exécution du travail;

Flèches de contrôle (incluses dans la face supérieure du bloc fonctionnel) - décrivent les règles et les restrictions en raison desquelles le travail est effectué;

Flèches de sortie (sortie du côté droit du bloc fonctionnel) - représentent des données ou des objets qui apparaissent à la suite du travail;

Les flèches du mécanisme (incluses dans le bord inférieur du bloc fonctionnel) - représentent les ressources (par exemple, l'équipement, les ressources humaines).

Le troisième concept de base de la norme IDEF0 est la décomposition. Le principe de décomposition est utilisé pour décomposer un processus complexe en ses fonctions constitutives.

La décomposition vous permet de représenter progressivement et structuré le modèle du système sous la forme d'une structure hiérarchique de diagrammes individuels, ce qui le rend moins surchargé et facile à digérer.

Le dernier des concepts IDEF0 est le glossaire. Pour chacun des éléments IDEF0: diagrammes, blocs fonctionnels, arcs d'interface, la norme existante implique la création et la maintenance d'un ensemble de définitions, mots-clés, récits, etc. appropriés, qui caractérisent l'objet affiché par cet élément. Cet ensemble est appelé un glossaire et est une description de l'essence de cet élément.

Considérez les schémas des processus métier qui se déroulent dans l'entrepôt du magasin OJSC DMM, «Cleonelly»:

Pour la visibilité générale du système, il est nécessaire de construire le contexte «Activité de l'entrepôt d'entreprise» (voir Figure 1.1).

Figure 1.1 - Schéma «Activité de l'entrepôt d'entreprise»

Une fois le contexte établi, la décomposition est effectuée, c'est-à-dire construire les diagrammes suivants dans la hiérarchie.

Chaque diagramme suivant est une description plus détaillée de l'une des œuvres du diagramme supérieur. Un exemple de décomposition du travail contextuel est présenté à la figure 1.2. Ainsi, l'ensemble du système est divisé en sous-systèmes au niveau de détail souhaité, ce système est divisé en trois niveaux.

Figure 1.2 - Diagrammes de décomposition de premier niveau

Figure 1.3 - Schéma «Enregistrement des marchandises»

Figure 1.4 - Schéma «Sortie de marchandises»

Figure 1.5 - Schéma «Enregistrement de marchandises»

DFD. Cette méthodologie est basée sur la construction d'un modèle du SI analysé - projeté ou réellement existant. Conformément à la méthodologie, le modèle de système est défini comme une hiérarchie de diagrammes de flux de données (DFD), décrivant le processus asynchrone de transformation des informations de son entrée dans le système à sa sortie vers l'utilisateur. Les diagrammes DFD sont généralement conçus pour visualiser le travail en cours du système de flux de travail d'une organisation. Le plus souvent, les diagrammes DFD sont utilisés pour compléter le modèle de processus métier implémenté dans IDEF0.

Les principaux composants d'un diagramme de flux de données sont:

Entités externes (représentées graphiquement sous forme de carré) - désignent un objet matériel ou un individu qui est une source ou un récepteur d'informations. Par exemple: clients, personnel, fournisseurs, clients, entrepôt;

Systèmes / sous-systèmes (ressemble graphiquement à un rectangle avec des coins arrondis) - œuvres désignant des fonctions ou des processus qui traitent et modifient les informations;

Les périphériques de stockage de données sont un dispositif abstrait pour stocker des informations qui peuvent être placées dans un périphérique de stockage à tout moment et après un certain temps peuvent être récupérées, et les méthodes de placement et de récupération peuvent être quelconques. La banque de données est généralement un prototype de la future base de données et la description des données qui y sont stockées devrait être liée au modèle d'information;

Flux de données - définit les informations transmises via une connexion de la source au récepteur. Le flux de données dans le diagramme est représenté par une ligne se terminant par une flèche qui indique la direction du flux.

Considérez le diagramme de flux de données sur les problèmes (DFD) Figure 1.6. Ce diagramme montre le mouvement des documents lorsqu'une «demande de produit» arrive dans une organisation.

Figure 1.6 - Diagramme DFD «Sortie de marchandises»

Considérez le diagramme de flux de données suivant "Dégagement du produit" (voir figure 1.7). Il montre le processus d'exécution des travaux et le mouvement des documents lors de la «sortie de marchandises».

Figure 1.7 - Graphique DFD «Dédouanement des marchandises»

Dans les diagrammes de flux de données, tous les symboles utilisés forment une vue d'ensemble, ce qui donne une idée claire des données utilisées et des fonctions exécutées par le système de flux de travail. Dans le même temps, il s'avère souvent que les flux d'informations existants qui sont importants pour les activités de l'entreprise ne sont pas mis en œuvre de manière fiable et doivent être réorganisés. *******

La structure organisationnelle d'une entreprise vendant des produits en éponge est considérée sur l'exemple de Donetsk Manufactura M, un magasin Cleonelly:

Dans le cadre du développement de systèmes de contrôle et de comptabilité matières, ils peuvent résoudre avec succès des problèmes:

1. Il s'agit du contrôle des marchandises livrées et stockées.

2. Informations sur les fournisseurs et les consommateurs

3. Il contient également des informations, des informations et des opérations sur le produit

4. Contient un journal de la déclaration des marchandises mainlevées

5. Contient un répertoire de produits

6. Automatisation des fonctions de l'entrepôt (réception, dépense, radiation, réservation de marchandises)

7. Enregistrement et stockage des factures pour les biens et services achetés et vendus, ainsi que facturation pour le paiement anticipé, le paiement différé et la livraison des marchandises

8. Création de factures et comptabilité des marchandises émises

9. Réalisation d'un inventaire des entrepôts avec création d'un état de collation, acte de pénurie et surplus

10. Création d'ensembles de marchandises

Comme indiqué, le principal domaine d'activité de cette entreprise est la vente de produits en coton. Le processus de conception comprend de nombreuses étapes soigneusement élaborées par les structures de gestion des entreprises de conception pendant toute la durée de vie de l'entreprise. Ce processus ne peut pas être modifié en une seule fois, car il implique de nombreux services de l'entreprise elle-même, des sous-traitants externes et des clients de l'entreprise de projet. Par conséquent, les entreprises hésitent à introduire des systèmes d'information liés aux processus de gestion de la conception et du développement. En règle générale, les entreprises russes utilisent leurs propres développements dans ce domaine.

1.3 Exigences de collecte

Lors de la conception du système d'information (SI) du «Poste de travail du magasin de gros», il était nécessaire de collecter des exigences qui permettraient de créer une interface de telle sorte que l'utilisateur final (employé du magasin) soit à l'aise avec le SI développé.

Le développement des exigences est le processus qui comprend les activités requises pour créer et approuver un document de spécification des exigences système.

Pour mettre en œuvre le processus d'automatisation de la comptabilité et du contrôle des matériaux, il est nécessaire que le système d'information puisse répondre aux exigences fonctionnelles suivantes:

¾ documenter les résultats.

¾ Le système d'information doit être implémenté en tant que programme basé sur l'environnement intégré de Visual Fox Pro.

Le programme fonctionne sous le système d'exploitation Windows 2000 / NT / XP.

Le processus d'élaboration des exigences comprend quatre étapes principales (Figure 1.8):

Analyse de la faisabilité technique de la création d'un système;

Formation et analyse des besoins;

Spécification des exigences et création de la documentation pertinente;

Attestation d'exigences.

La collecte des exigences est une étape importante de la conception logicielle, car c'est ici que toutes les exigences des clients doivent être correctement et correctement formulées.

1.4 Spécification des exigences

La détermination des exigences correctes est probablement l'étape la plus critique d'un projet logiciel. Il est très important que le format du projet corresponde aux exigences logicielles assemblées par l'équipe de développement, sinon ces exigences ne peuvent pas être prises en charge et présentées dans le produit logiciel. La spécification des exigences logicielles (SRS) est au cœur de tout le cycle de vie du développement logiciel. Ce n'est pas seulement un document dérivé qui définit les spécifications d'un projet logiciel, mais aussi le document principal utilisé pour la réalisation des tests de qualification et d'acceptation. L'attestation est une évaluation de la qualité du travail des chefs de projet. Il détermine le degré de conformité d'un produit logiciel aux exigences établies. La spécification SRS agit comme un mécanisme d'enregistrement des exigences du système qui sont utilisées comme critères d'attestation.

Sur la base du SRS, un accord est conclu entre les clients et les fabricants du produit logiciel. La spécification SRS décrit en détail les fonctions que le logiciel en cours de développement doit exécuter. Cela permet aux utilisateurs potentiels de déterminer dans quelle mesure le produit répond à leurs besoins, ainsi que les moyens de modifier le produit afin qu'il soit le plus utile pour résoudre leurs problèmes.

Diminue le temps de développement. Différents groupes au sein de l'organisation du client sont impliqués dans la préparation de la spécification SRS. Ils étudient minutieusement toutes les exigences avant même que le développement réel du projet ne commence. Cela réduit la probabilité d'une nouvelle conception, d'un codage et d'un test ultérieurs.

Un examen attentif des exigences de la spécification SRS peut révéler des oublis, des malentendus et des incohérences au début du cycle de développement, lorsque les problèmes sont beaucoup plus faciles à résoudre que plus tard.

La spécification SRS devient la base de l'estimation des coûts et de la planification. La description du produit est la véritable base pour estimer le coût d'un projet. Dans un environnement où le concept de proposition formelle existe, le SRS est utilisé pour approuver l'estimation d'une proposition ou d'un prix.

Avec des spécifications bien conçues, les SRS au niveau de l'organisation peuvent développer des plans de certification et d'audit beaucoup plus productifs. Dans le cadre du contrat de développement, le SRS fournit un point de référence pour évaluer le respect du cahier des charges.

La spécification SRS facilite le transfert du produit logiciel à de nouveaux utilisateurs, ainsi que son installation sur d'autres ordinateurs. Ainsi, il devient plus facile pour les clients de transférer le produit logiciel vers d'autres services de l'organisation et pour les développeurs de le transférer vers d'autres clients.

La spécification SRS sert de base à la modernisation. Ce document se concentre sur le produit lui-même, pas sur le processus de développement du projet, il peut donc être utilisé pour étendre le produit terminé.

Une fois le processus de définition et de spécification des exigences terminé, il est nécessaire de valider les exigences.

La spécification des exigences pour le projet logiciel doit être présentée à l'annexe A.

1.5 Attestation des exigences

La validation doit démontrer que les exigences définissent réellement le système que le client souhaite avoir. La validation des exigences est importante car une erreur dans la spécification des exigences peut entraîner une refonte du système et des coûts élevés si elle est découverte pendant le processus de développement du système ou après sa mise en production.

Au cours du processus d'attestation des exigences, divers types de vérifications de la documentation des exigences doivent être effectuées:

1. Vérification de l'exactitude des exigences.

2. Vérification de la cohérence.

3. Vérifiez l'exhaustivité.

4. Contrôle de faisabilité.

Il existe un certain nombre de méthodes d'attestation d'exigences qui peuvent être utilisées ensemble ou séparément:

1. Examen des exigences.

2. Prototypage.

3. Génération de scripts de test.

4. Analyse automatisée de la cohérence.

Le prototypage est le plus visible pour le client système.

Avant de démarrer le prototypage, vous pouvez créer un diagramme de flux d'interface utilisateur. Ce schéma permet d'étudier les relations entre les principaux éléments de l'interface utilisateur.

La prochaine étape de la validation des exigences est le prototypage direct.

Un prototype de logiciel est une implémentation partielle ou possible d'un nouveau produit proposé. Les prototypes vous permettent d'accomplir trois tâches principales: clarifier et compléter le processus de formulation des exigences, explorer des solutions alternatives et créer le produit final.

Le prototype du menu principal de ce module est illustré à la figure 1.9.

1.6 Choix d'une méthodologie de conception de système d'information

L'essence de l'approche structurelle du développement du SI réside dans sa décomposition (partition) en fonctions automatisées: le système est divisé en sous-systèmes fonctionnels, eux-mêmes divisés en sous-fonctions, subdivisés en tâches, etc. Le processus de partitionnement se poursuit jusqu'à des procédures spécifiques. En même temps, le système automatisé conserve une vue holistique dans laquelle tous les composants constitutifs sont interconnectés.

Toutes les méthodologies d'approche structurelle les plus courantes reposent sur un certain nombre de principes généraux. Les principes suivants sont utilisés comme deux principes de base:

Divide and Conquer - le principe de la résolution de problèmes complexes en les décomposant en de nombreux problèmes plus petits et indépendants, faciles à comprendre et à résoudre;

Le principe de l'ordre hiérarchique est le principe de l'organisation des parties constituantes d'un problème en arborescences hiérarchiques avec l'ajout de nouveaux détails à chaque niveau.

En analyse structurelle, il existe principalement deux groupes d'outils qui illustrent les fonctions remplies par le système et les relations entre les données. Chaque groupe de fonds correspond à certains types de modèles (schémas), les plus courants, parmi lesquels les suivants:

Modèles SADT (Structured Analysis and Design Technique) et schémas fonctionnels associés;

Diagrammes de flux de données DFD (Data Flow Diagrams);

Diagrammes d'entité-relation ERD (Entity-Relationship Diagrams).

Lors de la conception du SI, les modèles sont étendus, affinés et complétés par des schémas reflétant la structure du logiciel: architecture logicielle, schémas de principe de programme et schémas d'écran.

Les modèles énumérés ensemble donnent une description complète de la propriété intellectuelle, qu'elle soit existante ou nouvellement développée. La composition des schémas dans chaque cas spécifique dépend de l'exhaustivité requise de la description du système.

2 CONCEPTION DU SYSTÈME D'INFORMATION

2.1 Conception architecturale

Lors de la création de tout système d'information complexe, son architecture est un aspect critique, où elle représente une vision conceptuelle de la structure des futurs processus fonctionnels et technologies au niveau du système et en interconnexion. En règle générale, les systèmes d'information complexes des organisations sont conçus comme une composition de composants interactifs de haut niveau, qui peuvent eux-mêmes être des systèmes. L'architecture du système d'information d'une organisation rend le système plus facile à comprendre en définissant sa fonctionnalité et sa structure de manière à révéler les décisions de conception et à permettre à l'observateur de poser des questions sur la satisfaction des exigences de conception, l'attribution des fonctionnalités et la mise en œuvre des composants.

L'architecture du système d'information d'une organisation est un modèle de la façon dont la technologie de l'information soutiendra les principaux objectifs et la stratégie de développement d'un objet automatisé. Il vous permet de réfléchir de manière critique et d'articuler une vision de la manière dont les ensembles intégrés de systèmes d'information doivent être structurés pour atteindre ces objectifs. L'architecture du système d'information décrit comment les systèmes d'information, les applications et les personnes fonctionnent dans une organisation de manière uniforme et unifiée.

Ainsi, l'architecture d'un système d'information comprend un ensemble généralement accepté de composants qui fournissent les «briques» d'un système d'information. Ces «blocs de construction» et leurs caractéristiques sont définis au niveau de détail approprié pour répondre aux besoins des décisions de planification.

Lors de la conception des systèmes d'information modernes des organisations, leur architecture doit être développée en tenant compte de nombreux acteurs, elle doit être compréhensible pour les utilisateurs, permettre aux développeurs de faire un plan et des calendriers du système, permettre de définir des interfaces, des fonctions et des technologies clés, et également permettre d'estimer le calendrier et le budget du projet. Cela nécessite que les architectes des systèmes d'information modernes soient responsables de la création d'un concept satisfaisant et réalisable du système au stade le plus précoce de son développement, en maintenant l'intégrité de ce concept tout au long du développement et en déterminant l'adéquation du système résultant à une utilisation par le client. L'architecture des systèmes d'information, quant à elle, est le processus de description des architectures de systèmes d'information de manière suffisamment détaillée pour les rendre plus utiles à la conception des systèmes d'information.

L'étude de l'expérience étrangère montre que dans les pays développés, lors de l'élaboration d'une architecture de système d'information, les conditions suivantes doivent être remplies:

¾ se concentrer sur la mission de l'organisation;

¾ se concentrer sur les exigences;

¾ se concentrer sur le développement;

¾ la capacité d'adaptation;

¾ le besoin de flexibilité.

Le respect de toutes ces conditions permet de développer l'architecture du système d'information de l'organisation de manière plus parfaite et efficace.

Les principales architectures logicielles actuellement mises en œuvre sont:

¾ serveur de fichiers;

¾ client-serveur;

¾ multi-niveaux.

Serveur de fichiers ... Cette architecture de bases de données centralisées avec accès au réseau implique la désignation d'un des ordinateurs du réseau comme serveur dédié qui stockera les fichiers de la base de données centralisée. Conformément aux demandes des utilisateurs, les fichiers du serveur de fichiers sont transférés vers les postes de travail des utilisateurs, où la majeure partie du traitement des données est effectuée. Le serveur central ne remplit principalement que le rôle de stockage de fichiers, ne participant pas au traitement des données proprement dites. Une fois le travail terminé, les utilisateurs recopient les fichiers contenant des données traitées sur le serveur, d'où ils peuvent être récupérés et traités par d'autres utilisateurs. Cette organisation de la maintenance des données présente un certain nombre d'inconvénients, par exemple, lorsque de nombreux utilisateurs accèdent aux mêmes données en même temps, les performances de travail chutent fortement, car il faut attendre que l'utilisateur travaillant avec les données termine son travail. Dans le cas contraire, les modifications apportées par certains utilisateurs peuvent être écrasées par des modifications effectuées par d'autres utilisateurs.

Serveur client ... Ce concept est basé sur l'idée qu'en plus de stocker les fichiers de la base de données, le serveur central doit effectuer la majeure partie du traitement des données. Les utilisateurs accèdent au serveur central à l'aide d'un langage de requête structuré spécial (SQL, Structured Query Language), qui décrit la liste des tâches effectuées par le serveur. Les demandes des utilisateurs sont reçues par le serveur et y génèrent des processus de traitement de données. En réponse, l'utilisateur reçoit un ensemble de données déjà traité. L'ensemble des données n'est pas transféré entre le client et le serveur, comme c'est le cas dans la technologie du serveur de fichiers, mais uniquement les données dont le client a besoin. Une requête utilisateur de quelques lignes seulement peut générer un traitement de données impliquant de nombreuses tables et des millions de lignes. En réponse, le client ne peut recevoir que quelques numéros. La technologie client-serveur évite la transmission d'énormes quantités d'informations sur le réseau en transférant tout le traitement des données vers un serveur central. De plus, l'approche considérée permet d'éviter les conflits de modifications des mêmes données par plusieurs utilisateurs, qui sont typiques de la technologie de serveur de fichiers. La technologie client-serveur implémente une modification cohérente des données par plusieurs clients, garantissant l'intégrité automatique des données. Ces avantages et d'autres ont rendu la technologie client-serveur très populaire. Les inconvénients de cette technologie comprennent des exigences de performances élevées pour le serveur central. Plus les clients accèdent au serveur et plus la quantité de données traitées est importante, plus le serveur central doit être puissant.

Sur la base de ces considérations, lors de la conception de l'architecture AWS, la technologie client-serveur a été prise comme base. Les diagrammes de disposition montrent les relations physiques entre les composants logiciels et matériels d'un système.)

2.2 Conception de l'interface du système d'information

L'interface utilisateur est souvent comprise uniquement comme l'apparence du programme. Cependant, en réalité, l'utilisateur perçoit l'ensemble du système dans son ensemble à travers lui, ce qui signifie qu'une telle compréhension de lui est trop étroite. En réalité, l'interface utilisateur comprend tous les aspects de la conception qui affectent l'interaction entre l'utilisateur et le système. Ce n'est pas seulement l'écran que voit l'utilisateur. L'interface utilisateur se compose de nombreux composants, tels que:

un ensemble de tâches utilisateur qu'il résout à l'aide du système;

commandes du système;

navigation entre les blocs système;

conception visuelle des écrans de programmes.

Voici quelques-uns des avantages commerciaux les plus importants d'une bonne interface utilisateur:

réduire le nombre d'erreurs utilisateur;

réduire les coûts de maintenance du système;

réduction des pertes de productivité des employés lors de la mise en œuvre du système et récupération plus rapide de la perte de productivité;

améliorer le moral du personnel;

réduire le coût de modification de l'interface utilisateur à la demande de l'utilisateur;

disponibilité des fonctionnalités du système pour le nombre maximum d'utilisateurs.

AWP Wholesale Base est développé comme une application utilisant la technologie client-serveur.

2.2.1 Interface utilisateur du programme de commande

Le module principal "AWP Wholesale Base" est le module Luck.exe, qui fournit la mise en œuvre de la fonctionnalité principale du diagramme de cas d'utilisation présenté dans la Figure 1.9 de la Section 1.4.

Lors du développement d'un système d'information, l'une des tâches principales est de créer l'interface la plus simple et non chargée. C'est l'interface du produit logiciel qui aide les utilisateurs à «communiquer» avec le système d'information, agissant comme un dialogue entre l'utilisateur et le système.

Interface du programme, partie administrative:

1. forme de départ du programme. Ce formulaire est lancé au lancement du logiciel, formant ainsi le début d'un dialogue utilisateur avec le système (Figure 2.3);

2. formulaire d'administration. Sous cette forme, la gestion complète du système d'information est effectuée, c'est-à-dire ajouter, supprimer, modifier des données dans la base de données, ainsi que, si nécessaire, visualiser et imprimer des rapports (figure 2.4);

3. Formulaire «Clients», grâce à ce formulaire, vous pouvez voir des informations complètes sur les clients de l'entreprise (Figure 2.7);

4. Formulaire «Fournisseurs», grâce à ce formulaire, vous pouvez voir des informations complètes sur les clients de l'entreprise (Figure 2.8).

L'interface utilisateur du programme:

Dans la fenêtre d'arrivée des marchandises, les marchandises sont en cours de traitement. Lors du choix de cet onglet du formulaire, l'utilisateur doit d'abord

Dans le menu des dépenses, il y a des opérations effectuées par le magasinier pour la mainlevée et la vente de marchandises.

Dans le menu soldes, les marchandises sont comptées, les noms des articles stockés dans l'entrepôt.

Dans le menu de la caisse, les informations sur les commandes entrantes et sortantes sont stockées ici. (Captures d'écran)

2.2.2 Interfaces utilisateur des composants de contrôle

Fig 2.0 Menu principal du programme

La fenêtre principale du programme est illustrée à la Fig. 1.9. Comme vous pouvez le voir sur la figure, en plus du menu principal, déjà décrit ci-dessus, il contiendra également un panneau de contrôle (boutons "Revenu", "Consommation", "Accès", "Soldes", "Caissier", "Réévaluation", "Analytics", " Répertoires "," Service "et" Quitter le programme ").

Figure 2.1 Fenêtre de menu de réception ou de réception à l'entrepôt.

Figure 2.2 Fenêtre du menu Consommation

Figure 2.2 Fenêtre de menu régissant les droits d'accès au programme.

Figure 2.3 Fenêtre de menu du reste des marchandises.

Figure 2.4 Fenêtre du menu de la caisse enregistreuse.

Figure 2.4 Fenêtre du menu Réévaluation.

2.3 Conception de la base de données

ERwin 4.0 de Computer Associates Int a été utilisé pour concevoir la base de données.

ERwin est un outil de conception de base de données puissant et facile à utiliser qui a acquis une large acceptation et popularité. Il offre la plus grande productivité lors du développement et de la maintenance des applications de base de données. Tout au long du processus - de la modélisation logique des besoins d'information et des règles métier qui définissent la base de données, à l'optimisation du modèle physique en fonction des caractéristiques spécifiées - ERwin vous permet d'afficher visuellement la structure et les éléments de base de la base de données.

ERwin n'est pas seulement le meilleur outil de conception de base de données, mais aussi un outil pour en créer une rapidement. ERwin optimise le modèle en fonction des caractéristiques physiques de la base de données cible. Contrairement à d'autres outils, ERwin maintient automatiquement la cohérence logique et physique et traduit les constructions logiques, telles que les relations plusieurs-à-plusieurs, en implémentations physiques. Facilite la conception de la base de données. Pour ce faire, il suffit de créer un modèle graphique E-R (relation objet) qui satisfait toutes les exigences en matière de données et de saisir des règles métier pour créer un modèle logique qui affiche tous les éléments, attributs, relations et regroupements. Erwin a deux niveaux de présentation du modèle - logique et physique. La couche logique est une vue abstraite des données, sur laquelle les données sont présentées telles qu'elles apparaissent dans le monde réel et peuvent être appelées comme on les appelle dans le monde réel, par exemple, "Client fidèle", "Département" ou "Nom de famille de l'employé". Les objets de modèle représentés au niveau logique sont appelés entités et attributs. Le niveau logique du modèle de données est universel et n'a rien à voir avec une implémentation spécifique du SGBD. Il existe trois sous-niveaux du niveau logique du modèle de données, qui diffèrent par la profondeur de la présentation des informations sur les données:

Diagramme des relations d'entité (ERD);

Modèle basé sur les clés (KB);

Modèle entièrement attribué (FA).

Diagramme d'entité - La relation comprend des entités et des relations qui reflètent les règles métier de base du domaine. Un tel diagramme n'est pas trop détaillé, il comprend les principales entités et les relations entre elles qui satisfont aux exigences de base. Diagramme d'entité - Une relation peut inclure des relations plusieurs-à-plusieurs et ne pas inclure de descriptions de clés. En règle générale, ERD est utilisé pour des présentations et des discussions sur les structures de données avec des experts du domaine. Un modèle de données basé sur des clés est une vue plus détaillée des données. Il comprend une description de toutes les entités et clés primaires et est destiné à représenter la structure de données et les clés qui correspondent au domaine.

Un modèle logique est la représentation la plus détaillée d'une structure de données: il représente les données sous la troisième forme normale et inclut toutes les entités, attributs et relations (voir l'annexe B).

Modèle de données physique au contraire, cela dépend du SGBD spécifique, en fait, étant un affichage du catalogue système. La couche physique du modèle contient des informations sur tous les objets de la base de données. Comme il n'y a pas de normes pour les objets de base de données (par exemple, il n'y a pas de norme pour les types de données), la couche physique du modèle dépend de l'implémentation spécifique du SGBD. Par conséquent, plusieurs niveaux physiques différents de modèles différents peuvent correspondre au même niveau logique d'un modèle. Si, au niveau logique du modèle, le type de données spécifique de l'attribut n'a pas plus d'importance (bien que les types de données abstraits soient pris en charge), alors au niveau physique du modèle, il est important de décrire toutes les informations sur des objets physiques spécifiques - tables, colonnes, index, procédures, etc. ... La division du modèle de données en niveaux logiques et physiques vous permet de résoudre plusieurs problèmes importants.

Le modèle de données physiques est présenté à l'annexe B.

2.4 Justification du choix d'une plateforme de création d'un système d'information

Visual FoxPro est un environnement de développement visuel pour les systèmes de gestion de bases de données relationnelles actuellement disponibles auprès de Microsoft. La dernière version est la 9.0. Utilise le langage de programmation FoxPro. La version 7.0 du système peut fonctionner sur les noyaux Windows 9x et NT, les versions 8.0 et 9.0 - uniquement sur Windows XP, 2000, 2003.

FoxPro (Fox-pro?) Est l'un des dialectes du langage de programmation xBase. Il est principalement utilisé pour le développement de SGBD relationnels, bien qu'il soit possible de l'utiliser pour le développement d'autres classes de programmes.Comme indiqué ci-dessus, le langage VFP est un langage xBase fortement augmenté et étendu. Dans Visual FoxPro, un langage de programmation, c'est-à-dire que la construction de base d'un langage est le concept d'une classe. La version originale de xBase est le langage structuré le plus pur, avec un concept de base de procédures et de fonctions. Ainsi, le langage de programmation moderne Visual FoxPro vous permet de combiner à la fois la programmation «à l'ancienne» en décrivant un grand nombre de procédures et dans le style POO, en créant une hiérarchie de classes complexe.

J'ai choisi ce langage de programmation car il contient un certain nombre des avantages suivants:

¾ Un format de table de base de données bien connu qui facilite l'organisation de l'échange d'informations avec d'autres applications Microsoft Windows.

Organisation moderne des bases de données relationnelles, qui vous permet de stocker des informations sur les tables de base de données, leurs propriétés, index et relations, de définir des conditions d'intégrité référentielle, de créer des vues locales et distantes (Vues), des connexions serveur, des procédures stockées exécutées lorsque plus de 50 types d'événements différents se produisent (VFP 7.0-9.0).

Vitesse de travail élevée avec de grandes bases de données.

Haute visibilité du travail avec les bases de données: la fenêtre multifonctionnelle de session de données vous permet de voir la liste des tables de base de données ouvertes, leurs relations, les filtres, l'ordre des index, les modes de mise en mémoire tampon, le passage aux modes de modification de structure, de travailler avec les informations des tables, etc.

Vitesse élevée de développement d'applications à l'aide des assistants, des concepteurs, des constructeurs et du mode conseils IntelliSense lors de l'écriture de programmes, du débogage et du test des programmes.

Capacité à développer des applications client-serveur avec des données situées sur des serveurs de base de données Oracle et Microsoft SQL Server et avec d'autres applications Microsoft Windows en utilisant ODBC et OLE

Le système VFP est destiné à être utilisé par des programmeurs professionnels, il est donc inutile de russifier son menu et sa langue - pour tout programmeur, la syntaxe anglaise d'un langage algorithmique est plus familière que le russe.

2.5 Conception des modules

Arrêtons-nous plus en détail sur la conception de l'un des modules du programme et considérons, à l'aide de son exemple, les étapes nécessaires à la création d'un projet.

A titre d'exemple, je considérerai la conception d'un module qui implémente le cas d'utilisation "Emission d'une demande d'admission".

Tout d'abord, décrivons les flux d'événements qui se produisent dans ce cas d'utilisation.

Une condition préalable pour un cas d'utilisation est la réception d'une demande d'un client.

5. Le cas d'utilisation commence lorsque le client soumet l'application.

6. Le gestionnaire ouvre le formulaire Revenu.

7. Le gestionnaire fixe la date de la demande.

8. Le responsable met le nom du produit.

9. Le gestionnaire entre la quantité de marchandises reçues.

10. Le gestionnaire entre le montant de la demande.

11. Le responsable ferme le formulaire.

12. Le cas d'utilisation se termine.

La post-condition au cas d'utilisation est l'enregistrement d'une application dans le système et l'apparition d'un nouveau client dans le journal du formulaire principal.

Considérez un diagramme de séquence pour ce cas d'utilisation. Comme vous pouvez le voir sur ce schéma, le manager, en ouvrant le formulaire Arrivée, provoque l'exécution de plusieurs actions - automatiquement (du point de vue du manager) la date de la candidature est renseignée. La liste des clients lors du dépôt d'une candidature est remplie à partir de la base avec des informations primaires. Après cela, le gestionnaire entre toutes les données nécessaires et appuie sur le bouton «Accepter». Dans ce cas, les actions suivantes sont effectuées. Toutes les données sont transmises à la procédure stockée.

3 Mise en place et validation du système d'information

3.1 Mise en œuvre de l'application

La mise en œuvre de l'application, par essence, est l'une des étapes laborieuses pour le développeur du système d'information, car les exigences que le client met en avant doivent être clairement et correctement intégrées dans le système. À ce jour, il n’existe aucun logiciel qui puisse «s’adapter» aux exigences du soi-disant client et fournir un certain ensemble de fonctions pour la mise en œuvre du système qui répondrait à ces exigences. Par conséquent, chaque développeur doit choisir l'environnement optimal pour développer le système, mais il faut noter que lors de la mise en œuvre d'une application, on ne peut pas se passer d'écrire du code programme. C'est lors de l'écriture du code programme que certaines fonctions que le système doit exécuter seront implémentées. En fonction de l'environnement d'implémentation système sélectionné, le code du programme sera différent, dans un environnement tel que Microsoft Visual FoxPro, il y aura un code de programme, dans Visual Basic un autre, etc.

Dans ce cas, l'application a été implémentée dans Microsoft Visual FoxPro.

Les principales fonctions du système seront décrites ci-dessous:

1. La forme de départ du système. Ce formulaire est un formulaire de bouton et, par conséquent, chaque bouton remplit sa fonction. Le bouton d'enregistrement de l'administrateur est illustré à la figure 3.1. Ce bouton exécutera la fonction qui ouvre le panneau de l'administrateur, si l'utilisateur dispose de ces droits sur ce système.

2. Arrivée du bouton de menu. Ce bouton vous permet de garder une trace des marchandises entrantes dans l'entrepôt du magasin Figure 3.2.

3. Dans le bouton du menu, les dépenses sont enregistrées dans les registres des marchandises libérées de l'entrepôt Figure 3.3.

4. Dans le bouton du menu d'accès, les droits d'utilisation de ce programme sont réglementés Figure 3.4.

5. Dans le bouton du menu "restes" sont stockées des informations sur les matériaux stockés dans l'entrepôt du magasin Fig. 3.5.

6. Le bouton de menu de la caisse stocke des informations sur les commandes de caisse entrantes et sortantes.

7. Dans le bouton de menu réévaluation, les changements de prix pour le nouveau prix des marchandises sont effectués Fig.3.7.

Figure 3.1 - Formulaire de démarrage du système

Figure 3.2 - Forme de comptabilisation des entrées de marchandises à l'entrepôt.

Figure 3.3 - Forme de comptabilisation des marchandises mainlevées.

Figure 3.4 - Formulaire réglementant les droits d'accès au programme.

Figure 3.5 - Forme des restes de marchandises dans l'entrepôt.

Figure 3.5 - Formulaire sur les encaissements et les encaissements.

Figure 3.6 - Forme des opérations sur les marchandises.

Tester l'application

Le test est le processus d'exécution d'un programme pour détecter les erreurs. Les tests fournissent:

Détection d'erreur;

Démonstration de la conformité des fonctions du programme avec son objectif;

Démonstration de la mise en œuvre des exigences relatives aux caractéristiques du programme;

Affichage de la fiabilité comme indicateur de la qualité du programme.

La figure 3.2 montre les flux d'informations du processus de test.

Il y a trois flux à l'entrée du processus de test:

Texte du programme;

Données initiales pour démarrer le programme;

Résultats attendus.

Des tests sont effectués et tous les résultats obtenus sont évalués. Cela signifie que les résultats réels des tests sont comparés aux résultats attendus. Lorsqu'une incompatibilité est trouvée, une erreur est enregistrée et le débogage commence.

Après avoir collecté et évalué les résultats des tests, l'affichage de la qualité et de la fiabilité du logiciel commence. Si des erreurs graves nécessitant des modifications de conception sont régulièrement rencontrées, la qualité et la fiabilité du logiciel sont suspectes et la nécessité de renforcer les tests est déclarée.

Les résultats accumulés au cours des tests peuvent être évalués de manière plus formelle. Pour cela, on utilise des modèles de fiabilité logicielle qui prédisent la fiabilité sur la base de données réelles sur le taux d'erreur.

Il existe 2 principes de test logiciel:

Test fonctionnel (test boîte noire);

Essais structurels (essais en boîte blanche).

Lors du test de la méthode «boîte blanche», la structure interne du programme est connue. L'objet du test ici n'est pas le comportement externe, mais interne du programme. L'exactitude de la construction de tous les éléments du programme et l'exactitude de leur interaction les uns avec les autres sont vérifiées.

Les tests de boîte noire (tests fonctionnels) vous permettent d'obtenir des combinaisons de données d'entrée qui fournissent une vérification complète de toutes les exigences fonctionnelles du programme //. Un produit logiciel est ici considéré comme une "boîte noire" dont le comportement ne peut être déterminé qu'en examinant ses entrées et ses sorties correspondantes.

Le principe de la «boîte noire» n'est pas une alternative au principe de la «boîte blanche». Il s'agit plutôt d'une approche complémentaire qui détecte une classe d'erreurs différente.

Le test de la boîte noire recherche les catégories d'erreur suivantes:

Fonctionnalités incorrectes ou manquantes;

Erreurs d'interface;

Erreurs dans les structures de données externes ou lors de l'accès à une base de données externe;

Erreurs caractéristiques (capacité mémoire requise, etc.);

Erreurs d'initialisation et d'achèvement.

Contrairement aux tests en boîte blanche, qui sont effectués au début du processus de test, le test en boîte noire est utilisé dans les dernières étapes du test. Lors du test de la boîte noire, la structure de contrôle du programme est négligée. Ici, l'accent est mis sur la zone d'information de la définition du système logiciel. Les tests au cours de cette phase se concentrent sur l'adéquation de la solution à un environnement de production en direct. L'accent est mis sur la correction des bogues, l'identification de leur gravité et la préparation du produit pour sa sortie.

Au stade du test, deux tâches principales sont résolues:

Test de la solution - Les plans de test créés pendant la phase de planification et étendus et testés pendant la phase de développement sont exécutés;

Opération pilote - déploiement de la solution dans un environnement de test et test avec l'implication des futurs utilisateurs et la mise en œuvre de scénarios réels d'utilisation du système. Cette tâche est terminée avant le début de la phase de déploiement.

Le but de la phase de test est de réduire le risque qui survient lorsque la solution est mise en exploitation commerciale.

Pour que la phase de test soit réussie, il doit y avoir un changement d'attitude envers le projet et le développeur passe du développement de nouvelles fonctionnalités à l'assurance de la bonne qualité de la solution.

À ce stade de développement du système d'information, les types d'essais suivants doivent être effectués:

Les tests de base sont des tests techniques de bas niveau. Il est réalisé par le développeur lui-même lors du processus d'écriture du code du programme. La méthode "boîte blanche" est appliquée, risque élevé d'erreurs.

Test d'utilisabilité - Tests de haut niveau effectués par le testeur et les futurs utilisateurs du produit. La méthode «boîte noire» est appliquée.

Test alpha et bêta - En termes MSF, le code alpha est fondamentalement tout le code source qui a été créé pendant la phase de développement du modèle de processus MSF, et le code bêta est le code qui a été testé pendant la phase de test. Par conséquent, le code alpha est testé pendant la phase de développement du modèle de processus MSF, et le code bêta est testé pendant la phase de test.

Test de compatibilité - La solution en cours de développement nécessite une intégration et une interopérabilité avec les systèmes et solutions logicielles existants. Cette forme de test vise à tester l'intégrabilité et la capacité de la solution développée à interagir avec les systèmes existants. Dans ce cas particulier, l'exactitude de l'application sera vérifiée sur l'équipement de l'utilisateur et le logiciel utilisé par l'utilisateur.

Test de performance - axé sur la vérification de la conformité de l'application aux exigences de performance et au niveau de confort en termes de vitesse.

Test du système de documentation et d'aide - tous les documents de support et systèmes d'aide développés sont testés.

L'opération pilote teste une solution dans un environnement industriel. L'objectif principal de l'opération pilote est de démontrer que la solution est capable d'un fonctionnement stable dans des conditions industrielles et répond aux exigences de l'entreprise. Lors du fonctionnement pilote, la solution est testée en conditions réelles. L'opération pilote permet aux utilisateurs de fournir des commentaires sur les performances du produit. Guidé par cet avis, le promoteur élimine tous les problèmes possibles ou crée un plan d'action en cas de circonstances imprévues. En fin de compte, l'opération pilote permet de décider de lancer un déploiement complet ou de le reporter jusqu'à ce que les problèmes susceptibles de perturber le déploiement soient résolus.

Le plan d'exploitation pilote du système d'information développé est présenté dans le tableau 3.2.

Tableau 3.2 - Plan d'opération du pilote

Acte		La description
1. Choix des critères de succès		Le développeur et les candidats définissent les critères de réussite et s'entendent sur eux
2. Choix des utilisateurs et emplacement d'installation		Une équipe de participants aux tests pilotes du côté des utilisateurs et des développeurs est en cours de constitution. L'emplacement du déploiement du processus pilote est déterminé.
3. Préparation des utilisateurs et des sites d'installation		Formation des utilisateurs - participants de l'essai. Le site d'installation est en cours de préparation.
4. Déploiement d'une version de développement		Une version expérimentale est installée et incluse dans le travail.
5. Assistance et suivi de la version de développement		Suivi du travail des utilisateurs et du système, assistance à l'exploitation, collecte d'informations sur le fonctionnement du système
6. Commentaires des utilisateurs et évaluation des résultats		Les utilisateurs expriment leur opinion sur le fonctionnement du système, signalent les lacunes et les erreurs.
7. Introduction de modifications et d'ajouts	Les bogues sont corrigés, des modifications de conception ou de processus sont apportées. Les résultats corrigés sont fournis aux utilisateurs pour qu'ils travaillent et évaluent.
8. Décisions de déploiement	Si les résultats du travail de test pilote satisfont les utilisateurs, une décision est prise pour déployer le système.

3.2 Méthodologie de déploiement d'application

A ce stade, le développeur (ou l'équipe) déploie les technologies et les composants nécessaires à la solution, le projet passe à la phase de maintenance et de support, et le client l'approuve enfin. Après le déploiement, l'équipe évalue le projet et interroge les utilisateurs pour déterminer leur satisfaction.

Objectifs de la phase de déploiement:

¾  transférer la solution dans un environnement industriel;

¾  la reconnaissance par le client de l'achèvement du projet.

Le déploiement de composants spécifiques au site comprend plusieurs étapes: préparation, installation, formation et approbation formelle.

Les résultats de la phase de déploiement du système sont des systèmes de maintenance et de support, un référentiel de documents où se trouvent toutes les versions des documents et du code développés au cours du projet.

Pour déployer le système en cours de développement, un plan d'action a été élaboré, présenté dans le tableau 3.1.

Tableau 3.1 - Plan de déploiement d'application

Acte	Description de l'action
1. Sauvegarde	Les données de l'utilisateur sont sauvegardées avec sa participation et son approbation par le transfert d'informations sur un support amovible (CD, DVD)
2. Installation des composants de base de la solution	L'utilisation de technologies qui assurent le fonctionnement de la solution. Dans ce cas, installer le composant Visual FoxPro
3. Installation de l'application cliente	Transfert vers l'ordinateur de l'utilisateur et installation de la version finale du SI et de la base de données développés
4. Formation	Les utilisateurs sont formés pour travailler avec le système, le développeur est convaincu de l'exactitude et de la compréhension du travail de la propriété intellectuelle par les clients
5. Transfert de la base de connaissances du projet au client	Toute la documentation du projet est remise au client
6. Clôture du projet	Un rapport de clôture de projet est préparé. Le client signe le certificat d'acceptation.

Pour le fonctionnement normal de l'AWP, le système d'exploitation Microsoft WindowsXP est requis.

4 Gestion de projets d'information

4.1 Choix d'un cycle de vie de développement

L'un des concepts de base de la méthodologie de conception du SI est le concept de cycle de vie de son logiciel (logiciel de cycle de vie). Le cycle de vie d'un logiciel est un processus continu qui commence à partir du moment où une décision est prise sur la nécessité de le créer et se termine au moment de son retrait complet du service.

Le principal document réglementaire qui régit le cycle de vie des logiciels est la norme internationale ISO / CEI 12207 (ISO - Organisation internationale de normalisation - Organisation internationale de normalisation, CEI - Commission électrotechnique internationale - Commission internationale de génie électrique). Il définit la structure du cycle de vie, contenant les processus, actions et tâches à effectuer lors de la création du logiciel.

L'ISO / CEI 12207 ne propose pas de modèle de cycle de vie ni de méthodes de développement logiciel spécifiques. Le modèle de cycle de vie peut être compris comme une structure qui détermine la séquence d'exécution et l'interrelation des processus, des actions et des tâches exécutées au cours du cycle de vie. Le modèle de cycle de vie dépend des spécificités du SI et des spécificités des conditions dans lesquelles il est créé et fonctionne.

Il existe aujourd'hui de nombreux modèles du cycle de vie des logiciels, mais les plus populaires et les plus répandus sont deux modèles:

Modèle en spirale (voir figure 4.1);

Modèle itératif.

Figure 4.1 - Modèle en spirale du cycle de vie du logiciel

Créer un système d'information, c'est-à-dire «Lieu de travail automatisé de l'entrepôt de gros des employés de l'entrepôt», itératif a été choisi. Une caractéristique distinctive du modèle itératif est qu'il s'agit d'une méthode formelle, elle se compose de phases indépendantes, exécutées séquentiellement, et est sujette à des révisions fréquentes (Figure 4.2). L'approche itérative a bien fonctionné pour la construction de SI, pour lesquels, au tout début du développement, toutes les exigences peuvent être formulées avec suffisamment de précision et de détail pour donner aux développeurs la liberté de les mettre en œuvre au mieux d'un point de vue technique.

Avantages du modèle itératif:

le modèle est bien connu des consommateurs non logiciels et des utilisateurs finaux.

Commodité et facilité d'utilisation, car tout le travail est effectué par étapes (selon les phases du modèle);

Stabilité des exigences;

Le modèle est compréhensible;

Même le personnel mal formé (utilisateur inexpérimenté) peut être guidé par la structure du modèle;

Le modèle gère la complexité de manière ordonnée et fonctionne bien pour les projets qui sont raisonnablement compréhensibles;

Le modèle facilite la mise en œuvre d'un contrôle strict de la gestion de projet;

Facilite le travail du chef de projet pour planifier et assembler l'équipe de développement.

Figure 4.2 - Modèle itératif du cycle de vie du logiciel

Phases du modèle:

Au stade de l'analyse, ils définissent les fonctions que le système doit exécuter, mettent en évidence les plus prioritaires qui nécessitent une élaboration en premier lieu, décrivent les besoins d'information;

Au stade de la conception, les processus du système sont examinés plus en détail. Le modèle fonctionnel est analysé et, si nécessaire, corrigé. Des prototypes de systèmes sont en cours de construction;

Le système est en cours de développement au stade de la mise en œuvre;

Au stade de la mise en œuvre, le produit fini est introduit dans le système existant de l'organisation. La formation des utilisateurs est en cours;

Lors de la phase de maintenance, le produit logiciel est entretenu (tout ajout ou modification pour un fonctionnement plus fonctionnel du produit).

Le choix d'un modèle de cycle de vie de développement logiciel est une étape importante. Ainsi, pour un projet, le choix d'un modèle de cycle de vie de développement logiciel peut être effectué lors de l'utilisation des processus suivants.

Analyse des catégories distinctives du projet, placées dans les tableaux.

Répondez aux questions pour chaque catégorie, en mettant en évidence les mots «oui» et «non».

Classez par importance les catégories ou questions liées à chaque catégorie par rapport au projet pour lequel un modèle acceptable est sélectionné.

Équipe de développement ... En fonction des possibilités, la sélection du personnel pour l'équipe de développement a lieu avant même le choix du modèle du cycle de vie du développement logiciel. Les caractéristiques d'une telle équipe (voir Annexe G, Tableau G.1) jouent un rôle important dans le processus de choix d'un modèle de cycle de vie, ce qui signifie que l'équipe peut fournir une aide significative dans le choix d'un modèle de cycle de vie de produit logiciel, puisqu'elle est responsable de la mise en œuvre réussie du modèle de cycle de vie développé. ...

Équipe d'utilisateurs ... Aux étapes initiales du projet, vous pouvez obtenir une image complète de l'équipe d'utilisateurs (voir Annexe ET Tableau I.1) qui travaillera avec le logiciel développé, et ses relations futures avec l'équipe de développement tout au long du projet. Une telle vue aide à choisir un modèle approprié, car certains modèles nécessitent une participation accrue de l'utilisateur au développement et à l'étude du projet, puisque les exigences peuvent être légèrement modifiées par l'utilisateur au cours du processus de développement, le développeur doit alors connaître ces changements et comment présenter ces changements dans le logiciel.

4.2 Détermination de l'objectif et de la portée du projet logiciel

Le logiciel développé pour la comptabilisation des marchandises dans l'entrepôt automatisera le processus de réception, de structuration et de stockage des données sur les marchandises dans l'entrepôt, ainsi que de simplifier le processus d'émission des rapports.

Les objectifs du projet logiciel seront - la création et le déploiement d'un système de comptabilité des marchandises. Ce système est destiné à un usage interne par le personnel de Cleonelly, principalement des employés de l'entrepôt de l'entreprise.

Pour déterminer la portée du produit logiciel, il sera décrit ci-dessous ce qui devrait ou ne devrait pas être un projet logiciel.

Le projet logiciel doit être:

À usage interne dans une organisation;

Un projet pour la mise en place d'un accès multi-utilisateurs;

Un projet qui a la capacité d'entrer, de modifier et de stocker des informations sur le produit de l'entreprise;

Un projet qui a la capacité d'entrer, de modifier et de stocker des informations sur les utilisateurs du système;

Un projet qui a la capacité de saisir, modifier et stocker des informations sur les clients et les fournisseurs de l'organisation qui font l'objet de transactions à conclure;

Un projet qui effectuera la formation de rapports externes.

4.3 Établissement d'une structure pour une liste de travail opérationnelle

Pour créer un produit ou un service unique (résultat du projet), vous devez effectuer une certaine séquence de travail. La tâche de la planification du projet est d'estimer avec précision le calendrier et le coût de ces travaux. Plus l'évaluation est précise, plus la qualité du plan de projet est élevée. Pour donner une évaluation précise, vous devez avoir une bonne compréhension de la portée du projet, c'est-à-dire savoir quel type de travail doit être fait pour obtenir son résultat. Ce n'est qu'après l'établissement de la liste des travaux de conception que la durée de chacun d'eux est estimée et les ressources nécessaires à leur mise en œuvre sont allouées. Et ce n'est qu'alors qu'il est possible d'estimer le coût et le calendrier de chaque tâche et, à la suite de l'ajout, le coût total et la durée du projet. C'est pourquoi la définition du périmètre de travail est la première étape de la planification du projet. La détermination de la portée du travail de conception commence par la définition des étapes (ou phases) du projet. Par exemple, dans le projet de création d'un système "Comptabilisation des marchandises en stock", les phases suivantes peuvent être mises en évidence:

Développement des exigences logicielles;

Conception de système d'information;

Mise en place et certification du système d'information;

Mise en place du système.

Une fois la composition des phases et leurs résultats déterminés, il est nécessaire de déterminer la séquence de ces phases les unes par rapport aux autres et les délais de leur mise en œuvre. Ensuite, vous devez déterminer quels travaux les phases consistent, dans quel ordre ces travaux sont exécutés et quels délais vous devez respecter lorsqu'ils sont terminés.

La liste de travail étape par étape (Figure 4.3) a été conçue à l'aide d'un logiciel tel que MS Project 2003.

Figure 4.3 - Liste des travaux étape par étape

4.4 Estimation de la durée et du coût du développement logiciel

Estimation de la durée. Il est déterminé après la construction d'une liste étape par étape des travaux (Figure 4.3, paragraphe 4.3). Cette durée estimée peut être visualisée à l'aide du diagramme de Gantt (Annexe K).

Les diagrammes sont un moyen graphique d'afficher les informations contenues dans un fichier de projet. À partir de graphiques, vous pouvez avoir une idée visuelle de la séquence des tâches, de leur durée relative et de la durée du projet dans son ensemble.

Le diagramme de Gantt est l'un des moyens les plus populaires de représenter graphiquement un plan de projet et est utilisé dans de nombreux programmes de gestion de projet.

Dans MS Project, le diagramme de Gantt est le principal outil de visualisation du plan de projet. Ce graphique est un graphique avec une chronologie horizontale et une liste verticale de tâches. Dans ce cas, la longueur des segments indiquant les tâches est proportionnelle à la durée des tâches.

Sur le diagramme de Gantt, à côté des barres, des informations supplémentaires peuvent être affichées (à côté des tâches, les noms des ressources impliquées dans celles-ci et leur chargement lorsque la tâche est terminée sont affichés).

Estimation du coût

Le projet se compose de tâches , c'est-à-dire des activités visant à atteindre un certain résultat. Pour que la tâche soit terminée, ressources .

Une propriété importante des ressources est le coût (coût) de leur utilisation dans le projet. Il existe deux types de coûts de ressources dans MS Project: le taux basé sur le temps et le coût par utilisation.

Le taux basé sur le temps (taux) est exprimé dans le coût d'utilisation de la ressource par unité de temps, par exemple, 100 roubles par heure ou 1000 roubles par jour. Dans ce cas, le coût de participation de la ressource au projet sera le temps pendant lequel elle intervient dans le projet, multiplié par le taux horaire.

Dans ce cas, le taux basé sur le temps a été utilisé (Figure 4.4). Le coût total d'utilisation des ressources peut être vu dans la Figure 4.5.

Figure 4.4 - Taux de temps d'utilisation des ressources

Dans cette figure, vous pouvez voir que le développeur du système reçoit 50 roubles par heure lors de l'exécution d'un projet; un analyste commercial reçoit 45 roubles par heure, un testeur 38 roubles par heure. Les tarifs des heures supplémentaires ne sont pas inclus.

Figure 4.5 - Coûts totaux d'utilisation des ressources du projet

4.5 Allocation des ressources du projet

Un fragment de la répartition des ressources pour le système «Inventory Accounting» peut être vu dans la figure 4.6

Figure 4.6 - Un fragment de la répartition des ressources du projet

Pour chaque travail effectué dans le projet, une ressource est associée qui effectuera ce travail. La figure montre la quantité totale de travail pour chaque ressource et le nombre spécifique d'heures passées un jour spécifique.

4.6 Évaluation de l'efficacité économique du projet

Le calcul de l'efficacité économique du projet est une étape importante. C'est là que sera calculée l'efficacité économique du projet. Ce calcul montrera à quel point un projet ou un projet totalement non rentable est rentable. Lors du calcul de l'efficacité économique du projet, il sera nécessaire de calculer la période de récupération du projet. La période de récupération indiquera la période pendant laquelle le projet sera rentable.

Des données d'entrée.

Bénéfice supplémentaire de la mise en œuvre du projet (DP) \u003d 38 000 roubles. Des bénéfices supplémentaires ont été prévus par les experts de l'entreprise.

Investissement initial (IC) \u003d 39396,47 roubles. Les investissements initiaux correspondent aux coûts totaux d'utilisation des ressources du projet (Figure 4.5, clause 4.6)

Taux d'actualisation (i) \u003d 12%.

La période pour laquelle le projet est conçu (n) \u003d 2 ans.

Bénéfice supplémentaire de la mise en œuvre du projet (DP) \u003d 38 000 roubles.

Coûts annuels de mise en œuvre du projet (Z 1) \u003d 15 000 roubles.

Coûts annuels de mise en œuvre du projet (Z 2) \u003d 10 000 roubles.

Recettes de trésorerie annuelles (R 1) \u003d 23 000 roubles.

Recettes de trésorerie annuelles (R 2) \u003d 28 000 roubles.

Lors de l'évaluation des projets d'investissement, la méthode de calcul de la valeur actuelle nette est utilisée, qui prévoit l'actualisation des flux de trésorerie: tous les revenus et coûts sont ramenés à un moment donné.

L'indicateur central de la méthode considérée est la VAN (valeur actuelle nette) - la valeur actuelle des flux de trésorerie. Il s'agit d'un résultat final généralisé de l'activité d'investissement en termes absolus.

Un point important est le choix du taux d'actualisation, qui doit refléter le taux de prêt moyen attendu sur le marché financier.

La valeur actuelle nette (VAN) est calculée à l'aide de la formule 4.2

(4.2)

R k - encaissements annuels pendant n ans.

k - le nombre d'années pendant lesquelles le projet est conçu.

IC - investissement de démarrage.

i est le taux d'actualisation.

Selon les calculs de cette formule NPV \u003d 3 460,67 RUB

La VAN est un incrément absolu car elle estime à quel point le revenu actuel chevauche le coût actuel. Puisque NPV\u003e 0, le projet doit être accepté.

Le retour sur investissement (ROI) est calculé à l'aide de la formule 4.3

(4.3)

Calculé (ROI) \u003d 108,78%

Tableau 4.1  Tableau auxiliaire pour le calcul de la période de récupération du projet

= 1,84

Période de récupération n ok \u003d 1,84 an (1 an et 11 mois)

Puisque ROI \u003d\u003e 100% (soit \u003d \u200b\u200b108,78%), le projet est considéré comme rentable.

(4.4)

Ainsi, l'indice de rentabilité est (PI) \u003d 1,2

Les éléments qui assurent le fonctionnement du SI à quelque fin que ce soit sont énumérés dans la définition. Certains d'entre eux - moyens, méthodes et personnel - assurent le fonctionnement du SI, tandis que d'autres - stockage, traitement et émission d'informations - indiquent des caractéristiques fonctionnelles, c'est-à-dire déterminer à partir de quels processus d'information se compose le fonctionnement du SI. Par conséquent, la structure du SI est considérée de deux manières différentes: la structure fonctionnelle et la structure du SI comme un ensemble de sous-systèmes de support.

Conformément à la définition, les éléments fonctionnels du SI sont les groupes (blocs) de processus suivants:

entrée d'informations provenant de sources externes ou internes;

traiter les informations d'entrée et les présenter sous une forme pratique;

sortie d'informations pour présentation aux consommateurs ou transfert vers un autre SI;

les commentaires sont des informations traitées par les personnes d'une organisation donnée pour corriger les informations d'entrée.

Structure fonctionnelle Le système d'information est présenté sous la forme d'un bloc-diagramme (Fig.1), dans lequel chaque élément du système est représenté sous la forme d'un bloc (Fig. - un rectangle), et les liens et leurs directions sont indiqués par des flèches.

Les différents composants (blocs système) sont appelés sous-systèmes.

Dans chaque cas particulier, l'ensemble et les interrelations des sous-systèmes fonctionnels dépendent du domaine et des spécificités de l'activité de l'entreprise, dont l'activité est assurée par le système d'information.

La structure du SI peut également être représentée comme un complexe de sous-systèmes de support (Fig. 2).

Fig. 1. Schéma de principe IC fonctionnel généralisé.

Cependant, pour les AIS, qui diffèrent par la nature et les types de traitement de l'information, le schéma fonctionnel diffère dans un ensemble de sous-systèmes de traitement. Par exemple, les AIPS (bibliothèque, musée, référence juridique, etc.) produisent des entrées, des systématisations, des stockages, des recherches et des livraisons d'informations à la demande de l'utilisateur sans transformations de données complexes. Systèmes de résolution d'informations: ASOD, ACS, DSS - traitent les informations de la base de données selon un certain algorithme, mais ils diffèrent également dans la composition des sous-systèmes de traitement de l'information. Un système de CAO spécialisé dans l'automatisation de la conception a dans sa structure des sous-systèmes spéciaux: documentation technique, génération de tâches, simulation, calcul, et certains peuvent également avoir un système expert (voir le schéma de principe de la figure 2).

Fig. 2. Schéma fonctionnel CAO

Considérons un autre type de structure SI: comme un complexe de sous-systèmes de support (Fig. 3).

La structure d'un système d'information peut être considérée comme un ensemble de sous-systèmes, quel qu'en soit le périmètre. Un sous-système fait partie du système, sélectionné en fonction d'un attribut. Dans ce cas, ils parlent d'une caractéristique structurelle de la classification, et les sous-systèmes sont appelés fournir.

Ainsi, la structure de tout système d'information peut être représentée par un ensemble de sous-systèmes de support.

Fig. 3. Structure du SI par type de sous-systèmes de support.

Les informations, le support technique, mathématique, logiciel, organisationnel et juridique sont généralement distingués parmi les sous-systèmes de support.

Support d'information - un ensemble d'ensembles de données d'information, un système unifié de classification et de codage de l'information, des systèmes de documentation unifiés, des schémas de flux d'informations circulant dans une organisation, ainsi qu'une méthodologie de construction de bases de données. Le but du sous-système de soutien de l'information est la formation et la livraison en temps opportun d'informations fiables pour la prise de décisions de gestion.

Systèmes de documentation unifiés sont créés aux niveaux étatique, républicain, sectoriel et régional. Le principal objectif est d'assurer la comparabilité des indicateurs des différentes sphères de la production sociale. Des normes ont été élaborées là où les exigences sont établies:

aux systèmes de documentation unifiés;

à des formes unifiées de documents de différents niveaux de gestion;

à la composition et à la structure des détails et des indicateurs;

à la procédure de mise en œuvre, de mise à jour et d'enregistrement des formulaires unifiés de documents.

Malgré l'existence d'un système de documentation unifié, une enquête auprès de la plupart des organisations révèle tout un ensemble de lacunes typiques:

volume extrêmement important de documents pour traitement manuel;

les mêmes indicateurs sont souvent reproduits dans différents documents;

travailler avec un grand nombre de documents détourne les spécialistes de la résolution de problèmes immédiats;

il y a des indicateurs qui sont créés mais non utilisés, etc.

L'élimination de ces lacunes est l'une des tâches de la création d'un support informationnel.

Diagrammes de flux d'informations reflètent les itinéraires de circulation de l'information, ses volumes, les lieux d'origine des informations primaires et l'utilisation des informations qui en résultent. En analysant la structure de ces systèmes, il est possible de développer des mesures pour améliorer l'ensemble du système de gestion.

La construction et l'analyse détaillée de diagrammes de flux d'informations, permettant d'identifier les itinéraires et les volumes d'informations, la duplication des indicateurs et les processus de leur traitement, permet:

élimination des informations en double et inutilisées;

classification et présentation rationnelle des informations.

Méthodologie de création de base de données basé sur les fondements théoriques de leur conception.

Concepts de base de la méthodologie:

une compréhension claire des buts, objectifs, fonctions de l'ensemble du système de gestion de l'organisation;

identifier le mouvement de l'information depuis son origine jusqu'à son utilisation à différents niveaux de gestion, présentée pour analyse sous forme de schémas de flux d'informations;

amélioration du système de gestion des documents;

disponibilité et utilisation d'un système de classification et de codage;

connaissance de la méthodologie de création de modèles conceptuels de logique informationnelle qui reflètent l'interconnexion des informations;

création de tableaux d'informations sur des supports informatiques, ce qui nécessite un support technique moderne.

Ce concept est pratiquement mis en œuvre en deux étapes.

1ère étape - examen de toutes les divisions fonctionnelles de l'entreprise afin de:

comprendre les spécificités et la structure de ses activités;

construire un diagramme des flux d'informations;

analyser le système de gestion de documents existant;

définir des objets d'information et la composition correspondante des attributs (paramètres, caractéristiques), en décrivant leurs propriétés et leur objectif.

2ème étape - construction d'un modèle de données conceptuel information-logique basé sur les résultats de l'enquête de 1ère étape. Dans ce modèle, toutes les connexions entre les objets et leurs attributs doivent être établies et optimisées. Le modèle de logique informationnelle est la base sur laquelle la base de données sera créée.

Soutien technique - un ensemble de moyens techniques destinés au fonctionnement du système d'information, ainsi que la documentation correspondante pour ces moyens et procédés technologiques

L'ensemble des moyens techniques comprend:

ordinateurs de tout modèle;

dispositifs de collecte, d'accumulation, de traitement, de transmission et de sortie d'informations;

dispositifs de transmission de données et lignes de communication;

équipements et dispositifs de bureau pour la recherche automatique d'informations;

matériel d'exploitation, etc.

La documentation formalise la sélection préalable des moyens techniques, l'organisation de leur fonctionnement, le processus technologique de traitement des données, les équipements technologiques. La documentation peut être divisée en trois groupes:

à l'échelle du système, y compris les normes nationales et industrielles pour le soutien technique;

spécialisé, contenant un ensemble de méthodes pour toutes les étapes de développement du support technique;

référence normative, utilisée lors de l'exécution de calculs pour le support technique.

A ce jour, il existe deux formes principales d'organisation de l'appui technique (formes d'utilisation des moyens techniques): centralisée et partiellement ou totalement décentralisée.

Le support technique centralisé repose sur l'utilisation de grands ordinateurs et centres de calcul dans le système d'information. Cette forme d'organisation facilite la gestion et la mise en œuvre de la normalisation, mais réduit la responsabilité et l'initiative du personnel.

La décentralisation des moyens techniques implique la mise en œuvre de sous-systèmes fonctionnels sur des ordinateurs personnels directement sur les lieux de travail. Dans ce cas, plus de responsabilité personnelle est exigée du personnel, il est plus difficile pour la direction de mettre en œuvre la normalisation.

À l'heure actuelle, une approche partiellement décentralisée est plus répandue - l'organisation du support technique basée sur des réseaux distribués composés d'ordinateurs personnels et d'un mainframe pour stocker des bases de données communes à tous les sous-systèmes fonctionnels.

Mathématiques et logiciels - un ensemble de méthodes mathématiques, modèles, algorithmes et programmes pour la mise en œuvre des buts et objectifs du système d'information, ainsi que le fonctionnement normal du complexe de moyens techniques.

Vers les fonds logiciel rapporter:

outils de modélisation des processus de gestion;

tâches de gestion typiques;

méthodes de programmation mathématique, statistiques mathématiques, théorie des files d'attente, etc.

Partie logiciel comprend des produits logiciels à l'échelle du système et spéciaux, ainsi qu'une documentation technique.

À logiciel à l'échelle du système comprend des complexes de programmes destinés aux utilisateurs et conçus pour résoudre des problèmes typiques de traitement de l'information. Ils servent à étendre les fonctionnalités des ordinateurs, à contrôler et à gérer le processus de traitement des données.

Logiciel spécial est un ensemble de programmes développés lors de la création d'un système d'information spécifique. Il comprend des progiciels d'application (APP) qui mettent en œuvre les modèles développés à divers degrés d'adéquation, reflétant le fonctionnement d'un objet réel.

La documentation technique pour le développement du logiciel doit contenir une description des tâches, la tâche d'algorithmisation, le modèle économique et mathématique du problème, des exemples de test.

Soutien organisationnel Est un ensemble de méthodes et de moyens qui régulent l'interaction des travailleurs avec les moyens techniques et entre eux dans le processus de développement et d'exploitation des SI.

Le support organisationnel met en œuvre les fonctions suivantes:

analyse du système de gestion existant de l'organisation, où le SI sera utilisé, et identification des tâches à automatiser;

préparation de tâches à résoudre sur un ordinateur, y compris les termes de référence pour la conception du SI et une étude de faisabilité de son efficacité;

élaboration de décisions de gestion sur la composition et la structure de l'organisation, méthodologie de résolution des problèmes visant à améliorer l'efficacité du système de gestion.

Un soutien organisationnel est créé en fonction des résultats de l'enquête d'avant-projet à la 1ère étape de la construction de la base de données.

Support légal - un ensemble de normes juridiques qui déterminent la création, le statut juridique et le fonctionnement des systèmes d'information, réglementant la procédure d'obtention, de transformation et d'utilisation des informations.

Le principal objectif du soutien juridique est de renforcer l'état de droit. Le cadre juridique comprend les lois, les décrets, les décisions des autorités de l'État, les arrêtés, les instructions et autres documents normatifs des ministères, départements, organisations, autorités locales. Dans le support juridique, on peut distinguer une partie générale qui régule le fonctionnement de tout système d'information, et une partie locale qui règle le fonctionnement d'un système spécifique.

Le support juridique des étapes de développement d'un système d'information comprend les réglementations relatives à la relation contractuelle entre le développeur et le client et la réglementation légale des dérogations au contrat.

Le support juridique des étapes du fonctionnement du système d'information comprend:

état du système d'information;

droits, devoirs et responsabilités du personnel;

la procédure de création et d'utilisation des informations, etc.

Cet ensemble de sous-systèmes est général pour presque tous les types d'AIS. Cependant, la structure et la complexité des sous-systèmes de support dépendent du type d'AIS, du domaine d'application et d'autres facteurs. Ainsi, le sous-système de support mathématique a lieu dans l'AIS du développement logiciel d'origine - dans l'AIS avec un logiciel standard, il est absent. Le sous-système de soutien juridique peut être absent dans l'AIS à des fins intra-entreprise - dans ce cas, il est possible de se limiter au sous-système de soutien organisationnel, dans lequel, entre autres, les problèmes de soutien juridique sont résolus; L'AIS à des fins indépendantes, par exemple, les systèmes de services d'information, peut avoir un sous-système d'assistance juridique. Les AIS, qui disposent d'une base de données factuelle, ne disposent que d'un sous-système de support d'information, dans lequel il peut être nécessaire de résoudre certains problèmes linguistiques. Les AIPS documentaires disposent d'un sous-système développé de support linguistique, car ces systèmes résolvent des problèmes complexes consistant à garantir la pertinence sémantique des demandes des utilisateurs par rapport au contenu des documents émis. Et ce, en règle générale, ne sont pas seulement des modules logiciels d'analyse morphologique, mais aussi un ensemble de dictionnaires et de règles pour leur maintenance.

Les objectifs de la création et de la mise en œuvre de la propriété intellectuelle.

Que peut-on attendre de la mise en place des systèmes d'information?

La mise en œuvre des systèmes d'information peut contribuer à:

1. libération des travailleurs du travail de routine et son accélération grâce à l'automatisation;

2. remplacement des supports de données papier par des disques ou bandes magnétiques, ce qui conduit à une diminution du volume de documents sur papier, et donc à la possibilité d'une organisation plus rationnelle du traitement de l'information sur un ordinateur;

3. l'amélioration de la structure des flux d'informations et du système de gestion des documents dans l'entreprise grâce à l'effet de cohérence: saisie unique des données - utilisation multiple et polyvalente ";

4. obtenir des options plus rationnelles pour résoudre les problèmes de gestion (par l'introduction de méthodes mathématiques et de systèmes intelligents, etc.):

trouver de nouvelles niches de marché;

l'optimisation des coûts de production de produits et / ou services;

optimisation des relations avec les clients et les fournisseurs.

Les étapes de développement des systèmes d'information

L'histoire du développement de la propriété intellectuelle est divisée en étapes (tableau 2), correspondant approximativement à la numérotation acceptée des objectifs - l'approche de l'utilisation de la propriété intellectuelle est en train de changer.

Tableau 2. Étapes du développement de la propriété intellectuelle.

Période de temps	Concept d'utilisation de l'information	Type de systèmes d'information	But d'utilisation
1950 - 1960	Flux papier des documents de règlement	Systèmes d'information pour le traitement des documents de règlement sur les machines comptables électromécaniques	Augmenter la vitesse de traitement des documents Traitement des factures et traitement de la paie simplifiés
1960 - 1970	Aide de base à la préparation des rapports	Systèmes d'information de gestion pour les informations de production	Accélérer le processus de reporting
1970 - 1980	Contrôle de gestion de la mise en œuvre (ventes)	Systèmes d'aide à la décision Systèmes pour la haute direction	Sélection de la solution la plus rationnelle
1980 - 2000	L'information est une ressource stratégique qui offre un avantage concurrentiel	Systèmes d'information stratégique Bureaux automatisés	Survie et prospérité de l'entreprise

Les premiers systèmes d'information sont apparus au milieu du siècle dernier. Dans les années 1950, ils ont été conçus pour le traitement des factures et le calcul des salaires, et ont été mis en œuvre sur des machines comptables électromécaniques. Cela a conduit à une certaine réduction du coût et du temps de préparation des documents papier.

Années 60 sont marquées par un changement d'attitude à l'égard des systèmes d'information. Les informations obtenues auprès d'eux ont commencé à être utilisées pour des rapports périodiques de plusieurs manières. Ce jour-là, les organisations avaient besoin d'un équipement informatique polyvalent capable de remplir de nombreuses fonctions, et pas seulement de traiter les factures et de calculer les salaires, comme c'était le cas auparavant.

Dans les années 70 - début des années 80. les systèmes d'information commencent à être largement utilisés comme moyen de contrôle de gestion qui soutient et accélère le processus décisionnel.

À la fin des années 80. le concept d'utilisation des systèmes d'information change à nouveau. Ils deviennent une source d'information stratégique et sont utilisés à tous les niveaux d'une organisation de tout profil. Les systèmes d'information de cette période, fournissant les informations nécessaires à temps, aident l'organisation à réussir dans ses activités, créent de nouveaux produits et services, trouvent de nouveaux marchés de vente, fournissent des partenaires dignes, organisent la sortie de produits à bas prix et bien plus encore.

La compréhension moderne du système d'information implique l'utilisation d'un ordinateur personnel comme principal moyen technique de traitement de l'information. Dans les grandes organisations, avec un ordinateur personnel, la base technique d'un système d'information peut inclure un ordinateur central ou un supercalculateur. En outre, la mise en œuvre technique du système d'information en soi ne signifiera rien si le rôle de la personne à qui l'information est destinée n'est pas pris en compte et sans qui il est impossible de la recevoir et de la présenter.

Postes de travail à automatiser

Exigences de performance

Liste des rapports générés

4.4.2. Exigences pour un système de planification et de contrôle de la production

Le système d'information doit fournir une planification des ressources d'entreprise et une gestion de la production des commandes.

Conditions requises pour la fonctionnalité SI:

1. Gestion de la configuration des produits finis (PF):

Maintenir des informations normatives et de référence sur la composition du GP avec la possibilité d'indiquer la période de pertinence du cahier des charges et avec la possibilité d'être en production du GP avec plusieurs spécifications différentes;

Maintenir des informations normatives et de référence sur la technologie de fabrication des produits faisant partie du GP avec la possibilité d'indiquer la période de pertinence des technologies et avec la possibilité d'être en production du GP avec plusieurs technologies différentes;

2. Gestion des ventes:

Visualiser l'historique des relations clients;

Enregistrement / correction de la demande du client indiquant la liste des généralistes, les volumes, la date d'expédition, le prix de vente et les éventuelles conditions supplémentaires;

Visualiser les indicateurs économiques actuels (estimations de coûts) de l'entreprise publique commandée;

3. Planification de la production:

Formation d'un calendrier de disponibilité des équipements indiquant le nombre d'heures standard disponibles pour chaque jour de la période prévue;

Formation d'un plan de production indiquant le produit fabriqué, sa quantité, l'équipement utilisé, la division pour chaque jour de la période de planification;

Formation d'un plan pour les besoins de production en matériaux et composants;

Contrôle et gestion du chargement des équipements selon le plan de production formé;

Faire des ajustements au plan de production lors de son exécution;

Analyse plan-factuelle du plan de production;

4. Gestion de la production:

Formation des tâches de quart (commandes) pour la fabrication de produits;

Affecter / réaffecter les artistes interprètes aux commandes et fixer l'exécution des commandes, en indiquant le nombre de produits fabriqués, le nombre de produits défectueux et les motifs du mariage;

Gestion du stockage et du mouvement des articles en stock (biens et matériaux) en production;

5. Gestion de l'offre:

Formation sur la base du plan des besoins en matériaux et composants du bon de commande indiquant le fournisseur, la nomenclature des marchandises et des matériaux, la quantité et le délai de livraison;

Formation de bons de commande basés sur des commandes ponctuelles de biens et de matériaux des divisions;

Contrôler et suivre le processus de traitement des bons de commande;

Contrôle opérationnel des résidus;

Analyse plan-factuelle des livraisons;

6. Gestion des coûts:

Formation du coût prévu (standard) de l'entreprise publique;

Fixer les coûts de production réels;

Calcul du coût réel de l'entreprise publique;

Analyse des coûts réels du plan.

Conditions requises pour le calcul du coût standard d'une commande

Le coût standard du produit et de l'ensemble de la commande est calculé selon la méthode suivante:

1. La composante matérielle directe du coût standard d'un produit est formée sur la base d'informations concernant la composition standard de ce produit (spécification) et les prix comptables établis pour les articles en stock inclus dans cette spécification. Pour la spécification, l'utilisation de plusieurs postes de coûts matières est autorisée.

2. Le montant des salaires directs est calculé sur la base de la composition opérationnelle standard du produit. Sont fixés: la durée standard de chaque opération, la profession de travailleur requise pour cette opération, ainsi que le grade du travailleur. En outre, le système introduit des taux monétaires d'heures standard pour les professions de travailleurs et leurs catégories.

3. La valeur standard des coûts indirects est calculée en pourcentage de la base spécifiée (le montant des coûts directs pour l'élément spécifié).

Pour effectuer ce calcul, les données suivantes doivent être disponibles dans le système d'information:

1. Spécification de la fabrication du produit (ainsi que la spécification de la fabrication de tous les produits semi-finis de notre propre production inclus dans ce produit);

2. Technologie de fabrication du produit et des produits semi-finis qui y sont inclus: quelles opérations doivent être effectuées et à quel moment. De plus, pour chaque opération, la profession et la catégorie du travailleur sont précisées, nécessaires à sa mise en œuvre (pour la sortie de ce produit particulier);

3. Protocole de comptabilité des prix des biens et matériaux usagés;

4. Taux monétaires des heures standard pour les professions et les grades.

Conditions requises pour le calcul du coût réel de la commande

Le coût réel du produit et de l'ensemble de la commande est calculé selon la méthode suivante:

1. Les coûts directs des matières pour la production d'un produit sont calculés sur la base des données réelles sur le coût des matières par l'atelier pour les redistributions de production. Dans ce cas, le coût de tous les produits semi-finis inclus dans ce produit est d'abord calculé. L'évaluation globale est effectuée selon la méthodologie adoptée dans la politique comptable de l'entreprise.

2. Les salaires des travailleurs directs de la production sont calculés sur la base des données relatives à la fermeture des commandes. Dans le cas où les commandes ne sont pas enregistrées dans le SI, les salaires sont référés aux coûts directs soumis à distribution, c'est-à-dire distribués aux produits manufacturés selon une certaine base.

3. L'amortissement des équipements de production directe est inclus dans les coûts directs si pour chaque redistribution l'équipement (machine-outil) utilisé dans cette redistribution est indiqué.

4. Coûts directs à répartir:

Matières de base consommées moins fréquemment que pour chaque redistribution (par exemple, les produits chimiques, dont le taux par unité de production est si petit qu'il n'a aucun sens de prendre en compte leur consommation alternative même à ce taux);

Les salaires des travailleurs en l'absence d'informations sur leur répartition par chiffre d'affaires;

Amortissement des équipements directs si seul son montant mensuel total est disponible sans ventilation par redistribution.

Ces coûts sont attribués aux articles fabriqués en fonction de la base de distribution sélectionnée (par exemple, au prorata des coûts directs des matières).

1. Frais généraux de production (compte 25 BU): sont répartis entre les produits manufacturés au prorata de la base de distribution choisie. La part de ces dépenses peut ou non rester dans les travaux en cours selon la méthode comptable adoptée dans l'entreprise.

2. Les frais généraux de fonctionnement et frais commerciaux (comptes 26 et 44) sont comptabilisés en charges de la période en cours et concernent les frais commerciaux. La répartition de ces coûts sur le coût des produits finis peut être vue à l'aide d'un rapport spécial.

Exigences de performance du système d'information

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Exigences de fiabilité

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Exigences pour assurer un fonctionnement fiable (stable) du système d'information

Le fonctionnement fiable (stable) du Système d'Information doit être assuré par la mise en œuvre par le Client d'un ensemble de mesures organisationnelles et techniques dont la liste est donnée ci-dessous:

1. Organisation de l'alimentation électrique ininterrompue des équipements techniques;

2. Utilisation de logiciels sous licence;

3. Application régulière des recommandations du Ministère du travail et du développement social de la Fédération de Russie, énoncées dans le décret du 23 juillet 1998 sur l’approbation des normes intersectorielles de temps standard pour les travaux d’entretien des ordinateurs personnels et du matériel de bureau et de l’appui logiciel;

4. Respect régulier des exigences de GOST 51188-98. "Protection des données. Logiciel de test de la présence de virus informatiques ";

5. Sauvegarde régulière des bases de données du Système d'Information au moyen du Système d'Information lui-même ou au moyen du système de gestion de base de données utilisé.

Figure: 6.2.

(Système d'information d'entreprise)

Externalisation des systèmes d'information d'entreprise

L'externalisation des fonctions de production et des processus métiers basés sur les systèmes d'information de l'entreprise permet d'utiliser les dernières réalisations et les «meilleures pratiques» de la gestion moderne. La mise en place de systèmes d'information d'entreprise est au cœur de la réingénierie des processus métiers (Processus d'affaires...
(Externalisation et sous-traitance: technologies de haute gestion)

Modèles d'intégration des systèmes d'information d'entreprise

Les modèles d'intégration des systèmes d'information représentent le niveau supérieur de la classification des modèles de conception. De même que les modèles de niveaux inférieurs de classification, un groupe de modèles structurels est distingué parmi les modèles d'intégration. Les modèles structurels décrivent les principaux composants d'un seul ...
(Introduction à l'architecture logicielle)

TÂCHES FONCTIONNELLES DU SYSTÈME D'INFORMATION DE L'ENTREPRISE ET MODULES DE BASE DES SYSTÈMES D'INFORMATION MODERNES DE L'ENTREPRISE. INTÉGRATION DES MODULES

La signification significative du concept de module suppose une comparaison des sous-systèmes fonctionnels, des tâches fonctionnelles avec une approche fonctionnelle basée sur les tâches avec les principaux modules de Figure: 6.2. Comparaison des tâches fonctionnelles avec les principaux modules des systèmes d'information ICISP modernes d'une entreprise, ...
(Système d'information d'entreprise)

CONCEPT, HISTOIRE DU DÉVELOPPEMENT ET CLASSIFICATION DES SYSTÈMES D'INFORMATION DE L'ENTREPRISE. SYSTÈMES D'INFORMATION D'ENTREPRISE INTÉGRÉS DE L'ENTREPRISE

Le concept et la classification des systèmes d'information évoluent au cours de leur évolution historique. Cependant, l'objectif reste constant et est associé à l'atteinte de l'efficacité de la gestion d'entreprise. L'efficacité de la gestion d'entreprise dépend de l'interaction de nombreux facteurs, parmi lesquels: philosophiques, historiques, ...
(Système d'information d'entreprise)

CARACTÉRISTIQUES DES TECHNOLOGIES DE L'INFORMATION MODERNES DANS LES SYSTÈMES D'INFORMATION DE L'ENTREPRISE

TECHNOLOGIES MODERNES POUR L'ORGANISATION DE LA SAISIE DE DONNÉES DANS LES SYSTÈMES D'INFORMATION D'ENTREPRISE Les informations sur les transactions commerciales doivent être saisies en temps opportun dans la base de données opérationnelle à partir de toutes les sources de leur origine. Cela permettra d'organiser efficacement le traitement ultérieur des données en information ...
(Système d'information d'entreprise)

Interrelation des sous-systèmes d'information d'entreprise

Comment sont systèmes d'information au sein de l'entreprise? La voie habituelle pour une entreprise russe de taille moyenne est de commencer à mettre en œuvre la technologie de l'information en automatisant le travail du service comptable, du service RH et du workflow. Les données de ces systèmes sont les plus formalisées, les processus sont facilement automatisés. Les packages répandus "1C: Comptabilité", "Patron: Officier du personnel", "LanDocs", "LanStaff", "Salaire", etc. vous permettent de vous construire avec toutes les applications et, ainsi, de les intégrer dans le système d'information général de l'entreprise. Figure: 7.1 montre comment les modules du système d'information de l'entreprise sont liés les uns aux autres. Le module TPS sert les principaux processus de production et de support et est généralement la principale source d'autres modules d'information. L'ESS est le principal destinataire des données et des systèmes internes de l'environnement externe.

Figure: 7.1.

D'autres systèmes échangent également des données. Et ici se pose l'une des questions les plus difficiles pour un leader - recherche du degré d'intégration optimal... Il est tentant d'avoir un système complètement intégré, mais une telle intégration prend énormément de temps et coûte beaucoup d'argent. Et il vaut mieux ne même pas dire ce qu'il en coûte pour maintenir un tel système. Par conséquent, le besoin de systèmes intégrés doit être mis en balance avec la difficulté et le coût des circuits intégrés à grande échelle. Il n'y a pas de niveau standard d'intégration ou de centralisation - chaque leader doit indépendamment (ou avec l'aide d'un cabinet de conseil) pour résoudre ce problème difficile.

Liens entre DSS et TPS, KWS,