introduction

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

L'une des principales activités de la manufacture de Donetsk OJSC produit une large gamme de vêtements, principalement des peignoirs, des draps et des serviettes. De plus, l'entreprise produit du fil de coton teint pour le tissage et le tricotage.

Le développement des technologies de l'information automatisée va de pair avec l'émergence de nouveaux types de moyens techniques de traitement et de transmission de l'information, améliorant les formes d'organisation de l'utilisation de l'ordinateur, saturant l'infrastructure 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, le développement des technologies de l'information, leur amélioration, la diffusion des composants des technologies de l'information automatisées, en des produits logiciels particuliers 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 de services spécifiques - informations, 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 omniprésente 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 à la fois 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 suivi de leurs performances et d'analyse de 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.

L'objectif de ce projet de diplôme est la mise en place d'un poste de travail automatisé (AWP) permettant la comptabilité des produits dans un entrepôt magasin.

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

¾ analyser les processus commerciaux du magasin ;

¾ enquêter sur 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 la comptabilité des produits

¾ é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. Dans de tels systèmes, le contrôle et la comptabilité des matériaux sont effectués, ainsi que le traitement des informations reçues.

« 1C : Enterprise » est un système de solutions appliquées construit sur les mêmes principes et sur une seule plateforme technologique. Le responsable peut choisir une solution qui répond aux besoins actuels de l'entreprise et se développera au fur et à mesure que l'entreprise se développe 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 les entreprises modernes en développement dynamique sont confrontées. Solution de problèmes urgents de comptabilité et de gestion La composition des programmes du système 1C : Entreprise est axée sur les besoins réels des entreprises. L'entreprise "1C" produit des solutions logicielles sérialisées conçues pour automatiser les tâches de comptabilité et de gestion typiques des entreprises. Une caractéristique distinctive des solutions de l'édition 1C est une étude approfondie de la composition des fonctionnalités incluses dans les solutions standard. L'entreprise "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 faible de la 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 défaillances du système de communication.

¾ Facilité d'utilisation de l'interface ;

¾ Un niveau élevé 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 à toutes les étapes de l'exploitation, mais également le suivi des actions effectuées avec un haut degré de fiabilité.

1.2 Analyse du 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 haut niveau Fusion Process Modeler (BPwin) prenant en charge les méthodologies IDEF0 (modèle fonctionnel), DFD (Dataflow Diagram) et IDEF3 (Workflow Diagram). BPwin est un produit 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 permettant de collecter toutes les informations pertinentes sur le fonctionnement de l'entreprise et de représenter graphiquement ces informations sous la forme d'un modèle cohérent et homogène.

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 présentées. Le modèle fonctionnel est conçu pour décrire les processus métier existants dans l'entreprise (le modèle dit AS-IS) et la situation idéale – ce qu'il faut rechercher (modèle TO-BE). La méthodologie IDEF0 prescrit la construction d'un système hiérarchique de diagrammes, c'est-à-dire descriptions uniques de fragments de 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 (schémas 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 permet de basculer vers n'importe quelle branche du modèle en notation DFD ou IDEF3. Les diagrammes de diagramme de flux de données (DFD) 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 commerciales 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 exécutés dans l'entrepôt du 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 la définition du 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 marchandise », « Sortie de marchandise », considérons les schémas qui sont présentés sous forme de schéma IDEF0. Le système IDEF0 est présenté comme un ensemble d'activités ou de fonctions en interaction.

La méthodologie IDEF0 repose sur quatre concepts principaux.

Le premier est le concept bloc fonctionnel (Boîte d'activité)... 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) spécifique, tandis que :

Le côté supérieur est le contrôle ;

Le côté gauche est Input;

Le côté droit est défini sur Sortie ;

Le côté inférieur est réglé sur Mécanisme.

La deuxième "baleine" de la méthodologie IDEF0 est le concept d'arc d'interface (flèche). 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 qui se déroulent dans le système. Dans ce cas, les flèches, selon quelle face du rectangle de travail elles entrent ou quelle face elles sortent, se divisent en :

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 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 d'un travail ;

Les flèches du mécanisme (incluses dans le bord inférieur du bloc fonctionnel) - représentent des ressources (par exemple, équipement, 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 de manière structurée 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 : schémas, blocs fonctionnels, arcs d'interface, la norme existante implique la création et la maintenance d'un ensemble de définitions, mots-clés, narrations, etc. pertinents qui caractérisent l'objet affiché par cet élément. Cet ensemble s'appelle un glossaire et est une description de l'essence de cet élément.

Considérez les diagrammes des processus métier se produisant 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 de l'entreprise » (voir Figure 1.1).

Figure 1.1 - Diagramme "Activités d'entrepôt de l'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 "Dédouanement des marchandises"

Figure 1.4 - Schéma « Sortie de marchandises »

Figure 1.5 - Schéma « Dépôt des marchandises »

DFD. Cette méthodologie repose sur la construction d'un modèle du SI analysé - projeté ou 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 depuis leur entrée dans le système jusqu'à leur sortie vers l'utilisateur. Les diagrammes DFD sont généralement construits pour visualiser le travail actuel 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 (ressemblant graphiquement à un rectangle avec des coins arrondis) - travaux désignant des fonctions ou des processus qui traitent et modifient les informations ;

Les stockages de données sont un dispositif abstrait pour stocker des informations qui peuvent être mises dans un lecteur à 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 n'importe lesquelles. En général, le magasin de données est un prototype de la future base de données et la description des données qui y sont stockées doit être liée au modèle d'information ;

Flux de données - définit les informations transmises via une certaine 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 le sens du flux.

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

Figure 1.6 - Schéma DFD « Sortie Marchandises »

Considérez le diagramme de flux de données suivant « Liquidation 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 - Diagramme DFD "Dédouanement des marchandises"

Dans les diagrammes de flux de données, tous les symboles utilisés forment une vue d'ensemble, qui donne une idée claire des données utilisées et des fonctions exécutées par le système de workflow. Dans le même temps, il s'avère souvent que les flux d'informations existants et 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 la société OJSC « Donetsk Manufactura M » du magasin de Cleonelly :

Dans le sens du développement de systèmes de contrôle et de comptabilité des matériaux, 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 et des opérations sur le produit

4. Contient un journal du rapport de marchandises validé

5. Contient un répertoire de marchandises

6. Automatisation des fonctions d'entrepôt (réception, consommation, annulation, réservation de marchandises)

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

8. Création des factures et comptabilisation des marchandises émises

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

10. Création d'ensembles de marchandises

Comme indiqué, le principal domaine d'activité de cette entreprise est la vente de produits cotonniers. 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 même temps, 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 se méfient de la mise en œuvre 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 du système.

Pour mettre en œuvre le processus d'automatisation de la comptabilité et du contrôle des matières, 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é comme un programme basé sur l'environnement intégré Visual Fox Pro.

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

Il y a quatre étapes principales dans le processus de développement des exigences (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 des exigences.

Le recueil des exigences est une étape importante dans la conception d'un logiciel, puisque c'est ici que toutes les exigences des clients doivent être correctement et correctement formulées.

1.4 Spécification des exigences

Déterminer les exigences correctes est probablement l'étape la plus critique dans un projet logiciel. Il est très important que le format du projet corresponde aux exigences du logiciel assemblé 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 l'ensemble du cycle de vie du développement logiciel. Il s'agit non seulement d'un document dérivé qui définit les spécifications d'un projet logiciel, mais également du document principal utilisé dans le but de réaliser des tests de qualification et de recette. 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 avec les 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 produit logiciel développé 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. Divers 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 le début du développement réel du projet. Cela réduit la probabilité de reconception, de codage et de test ultérieurs.

Une étude minutieuse 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 valider l'estimation d'une proposition ou d'un prix.

Avec des spécifications bien rédigées, les SRS au niveau organisationnel 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 départements de l'organisation et pour les développeurs de transférer le produit vers d'autres clients.

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

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 du 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 service.

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

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

2. Vérification de la cohérence.

3. Vérification de 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 cohérence.

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

Avant de commencer le prototypage, vous pouvez créer un organigramme de l'interface utilisateur. Ce diagramme 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 Choisir 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 (division) 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. Dans le même temps, le système automatisé maintient une vue holistique dans laquelle tous les composants sont interconnectés.

Toutes les méthodologies d'approche structurelle les plus courantes sont basées 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 indépendants plus petits, faciles à comprendre et à résoudre ;

Le principe de l'ordre hiérarchique est le principe d'organiser les éléments constitutifs 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 exécutées 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 entité-relation ERD (Entity-Relationship Diagrams).

Au stade de la conception du SI, les modèles sont étoffés, affinés et complétés par des schémas reflétant la structure du logiciel : architecture logicielle, schémas blocs programmes et schémas écrans.

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

2 CONCEVOIR LE SYSTÈME D'INFORMATION

2.1 Conception architecturale

Lors de la création de tout système d'information complexe, un aspect critique est son architecture, 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 facilite la compréhension du système en définissant sa fonctionnalité et sa structure d'une manière qui révèle les décisions de conception et permet à l'observateur de poser des questions sur le respect des exigences de conception, l'allocation 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 penser de manière critique et d'articuler une vision de la façon 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 « blocs de construction » 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 nombreuses parties prenantes, elle doit être compréhensible pour les utilisateurs, permettre aux développeurs de planifier et de programmer le système, permettre de définir les interfaces, fonctions et technologies clés, et également permettre d'estimer le calendrier et le budget du projet. Cela exige de la responsabilité des architectes des systèmes d'information modernes de créer un concept satisfaisant et exploitable du système au stade le plus précoce de son développement, de maintenir l'intégrité de ce concept tout au long du développement et de déterminer l'adéquation du système résultant à une utilisation par le client. L'architecture du système d'information, d'autre part, est le processus de description des architectures du système d'information de manière suffisamment détaillée pour les rendre plus utiles pour la conception du système d'information.

L'étude des expériences étrangères 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 plus parfaite et plus 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 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ù l'essentiel du traitement des données est effectué. Le serveur central ne remplit principalement que le rôle de stockage de fichiers, ne participant pas au traitement des données lui-même. Une fois le travail terminé, les utilisateurs copient les fichiers contenant les 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, puisqu'il faut attendre que l'utilisateur travaillant avec les données termine son travail. Sinon, les modifications apportées par certains utilisateurs peuvent être écrasées par les modifications apportées par d'autres utilisateurs.

Serveur client... Ce concept repose 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 une liste de 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 des serveurs 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 vous permet d'éviter la transmission d'énormes quantités d'informations sur le réseau en déplaçant tout le traitement des données vers un serveur central. De plus, l'approche envisagée évite 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 quelques autres ont rendu la technologie client-serveur très populaire. Les inconvénients de cette technologie incluent 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 Concevoir 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 à travers lui l'ensemble du système dans sa globalité, 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 l'utilisateur voit. 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 ;

contrôles du système;

navigation entre les blocs système ;

conception visuelle des écrans de programme.

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

réduire le nombre d'erreurs de l'utilisateur ;

réduire le coût de maintenance du système ;

réduction des pertes de productivité des salariés lors de la mise en place 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 des utilisateurs ;

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

La base de vente en gros AWP est développée en tant qu'application utilisant la technologie client-serveur.

2.2.1 Interface utilisateur du programme de commande

Le module principal de la « AWP Wholesale Base » est le module Luck.exe, qui fournit la mise en œuvre des principales fonctionnalités du diagramme de cas d'utilisation présenté à 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 la moins 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é lors du lancement du produit 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 réalisée, c'est-à-dire l'ajout, la suppression, la modification des données dans la base de données, ainsi que, si nécessaire, la visualisation et l'impression 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, l'enregistrement des marchandises est en cours. En choisissant 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 sortie et la vente des marchandises.

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

Dans le menu du caissier, les informations sur les ordres de crédit et les ordres de sortie de fonds 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 "Revenus", "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égulant 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 Revalorisation.

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 productivité la plus élevée lors du développement et de la maintenance d'applications de base de données. Tout au long du processus - de la modélisation logique des exigences d'information et des règles métier qui définissent la base de données à l'optimisation du modèle physique conformément aux 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 optimisera 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 répond à 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 elles sont appelées dans le monde réel, par exemple, "Client fidèle", "Département" ou " Nom de l'employé". Les objets de modèle qui sont 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 présentation des informations sur les données :

Diagramme de relations d'entité (ERD) ;

Modèle basé sur la clé (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 commerciales de base du domaine. Un tel schéma n'est pas trop détaillé, il comprend les entités principales 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 clés. En règle générale, l'ERD est utilisé pour les présentations et les discussions sur la structure des données avec des experts en la matière. 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 des 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 une troisième forme normale et comprend 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 du système. La couche physique du modèle contient des informations sur tous les objets de la base de données. Puisqu'il n'y a pas de normes pour les objets de base de données (par exemple, il n'y a pas de normes 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 à un 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 beaucoup 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... Diviser le 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 physique est présenté à l'annexe B.

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

Visual FoxPro est un système de gestion de base de données relationnelle visuelle actuellement disponible auprès de Microsoft. La dernière version est la 9.0. Utilise le langage de programmation FoxPro. La version du système 7.0 peut fonctionner sur les systèmes d'exploitation Windows 9x et les noyaux NT, versions 8.0 et 9.0 - uniquement sous Windows XP, 2000, 2003.

FoxPro est l'un des dialectes du langage de programmation xBase. Il est principalement utilisé pour le développement de SGBD relationnel, 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 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 basique de procédures et de fonctions. Ainsi, le langage de programmation moderne Visual FoxPro permet de combiner à la fois la programmation "à l'ancienne" en décrivant une masse de procédures, et dans le style POO, créant une hiérarchie de classes complexe.

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

¾ Format bien connu des tables de bases de données, qui permet d'organiser facilement 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, définir des conditions d'intégrité référentielle, créer des vues locales et distantes, 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).

Grande vitesse de travail avec de grandes bases de données.

Grande visibilité de l'utilisation des bases de données : la fenêtre de session de données multifonctionnelle vous permet de voir une 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, de passer aux modes de modification de structure, de travailler avec les informations des tables, etc.

Grande vitesse de développement d'applications à l'aide des assistants, des concepteurs, des constructeurs et du mode d'indications IntelliSense lors de l'écriture du texte du programme, un système de débogage et de test des programmes.

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

Le système VFP est destiné à être utilisé par des programmeurs professionnels, il ne sert donc à rien 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 de modules

Arrêtons-nous plus en détail sur la conception d'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 "Emet 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 à 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 Revenus.

7. Le gestionnaire fixe la date de la demande.

8. Le responsable met le nom du produit.

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

10. Le gestionnaire entre le montant de la demande.

11. Le gestionnaire ferme le formulaire.

12. Le cas d'utilisation se termine.

La postcondition 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 gestionnaire, en ouvrant le formulaire d'arrivée, provoque l'exécution de plusieurs actions - automatiquement (du point de vue du gestionnaire) la date de la demande est renseignée. Lors du dépôt d'une candidature, la liste des clients est renseignée à partir de la base avec les informations primaires. Après cela, le gestionnaire entre toutes les données nécessaires et clique 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, dans son essence, est une des étapes laborieuses pour le développeur du système d'information, car les exigences formulées par le client doivent être clairement et correctement intégrées dans le système. Jusqu'à présent, il n'y a pas de produits logiciels qui pourraient « 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 convient de noter que lors de la mise en œuvre d'une application, on ne peut pas se passer d'écrire du code de programme. C'est lors de l'écriture du code du programme que seront implémentées certaines fonctions que le système devra exécuter. Selon l'environnement sélectionné pour la mise en œuvre du système, le code du programme aura un aspect 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 propre 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 a de tels droits sur ce système.

2. Arrivée du bouton de menu. Ce bouton vous permet de suivre les 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 sorties 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.Fig.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 du menu de la caisse enregistre les informations sur les ordres de caisse entrants et les ordres de caisse sortants Figure 3.6.

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

Figure 3.1 - La forme de départ 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 dédouanées.

Figure 3.4– Formulaire régulant les droits d'accès au programme.

Figure 3.5– Forme du reste des 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 afin de 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 pour les 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 existe 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 indiquée.

Les résultats accumulés lors des tests peuvent être évalués de manière plus formelle. Pour cela, des modèles de fiabilité logicielle sont utilisés 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 :

Tests fonctionnels (tests boîte noire) ;

Tests structurels (tests 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 le comportement 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 les 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 différente d'erreurs.

Les tests de boîte noire recherchent les catégories d'erreurs suivantes :

Fonctionnalités incorrectes ou manquantes ;

Erreurs d'interface ;

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

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

Erreurs d'initialisation et d'achèvement.

Contrairement au test boîte blanche, qui est effectué au début du processus de test, le test boîte noire est utilisé dans les étapes ultérieures 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 et l'identification de leur gravité, ainsi que sur la préparation du produit pour la publication.

Au stade des tests, deux tâches principales sont résolues :

Test de 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 de test avec l'implication des futurs utilisateurs et la mise en place de scénarios réels d'utilisation du système. Cette tâche est effectuée avant le début de la phase de déploiement.

La phase de test a pour objectif de réduire le risque qui survient lors de la mise en exploitation commerciale de la solution.

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

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

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

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

Tests alpha et bêta - En termes MSF, le code alpha est essentiellement tout le code source 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 doit pouvoir s'intégrer et interagir avec les systèmes et solutions logicielles existants. Cette forme de test est axée sur le test de l'intégrabilité et de la capacité de la solution développée à interagir avec les systèmes existants. Dans ce cas particulier, le bon fonctionnement de l'application sur l'équipement de l'utilisateur et le logiciel utilisé par l'utilisateur seront vérifiés.

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

Test de la documentation et du système 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 de fonctionner de manière stable dans des conditions industrielles et répond aux exigences de l'entreprise. Lors de l'exploitation pilote, la solution est testée en conditions réelles. Le fonctionnement pilote permet aux utilisateurs de fournir des commentaires sur les performances du produit. Guidé par cet avis, le développeur élimine tous les problèmes possibles ou crée un plan d'action en cas d'imprévu. En fin de compte, l'opération pilote vous permet de décider de démarrer un déploiement à grande échelle ou de le reporter jusqu'à ce que tous les problèmes susceptibles de faire dérailler le déploiement soient résolus.

Le plan du processus 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 pilote

action		La description
1. Choix des critères de réussite		Le développeur et les testeurs définissent les critères de réussite et s'accordent sur eux
2. Choix des utilisateurs et du lieu d'installation		Une équipe de participants aux tests expérimentaux du côté des utilisateurs et des développeurs est en cours de formation. L'emplacement du déploiement du processus pilote est déterminé.
3. Préparation des utilisateurs et des sites d'installation		La formation des utilisateurs - les participants à l'essai est en cours. 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. Support et suivi de la version de développement		Surveillance du travail des utilisateurs et du système, assistance au fonctionnement, collecte d'informations sur le fonctionnement du système
6. Retour 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 erreurs sont corrigées, des modifications de conception ou de processus sont apportées. Les résultats corrigés sont fournis pour que les utilisateurs puissent travailler et évaluer.
8. Décisions de déploiement	Si les résultats du travail de test pilote satisfont les utilisateurs, la décision est prise de déployer le système.

3.2 Méthodologie de déploiement des applications

A ce stade, le développeur (ou l'équipe) déploie les technologies et composants nécessaires à la solution, le projet passe au stade de la maintenance et du 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 ;

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

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

Les résultats de l'étape 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é, qui est présenté dans le tableau 3.1.

Tableau 3.1 - Plan de déploiement des applications

action	Description de l'action
1. Sauvegarde	Les données de l'utilisateur sont sauvegardées avec sa participation et son approbation en transférant les informations sur des supports amovibles (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, l'installation du composant Visual FoxPro
3. Installation de l'application cliente	Transfert sur l'ordinateur de l'utilisateur et installation de la version finale du SI développé et de la base de données
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 du projet est préparé. Le client signe le certificat de réception.

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

4 Gestion de projet d'information

4.1 Choisir un cycle de développement

L'un des concepts de base de la méthodologie de conception du SI est la notion de cycle de vie de son logiciel (life cycle software). 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 sa mise hors service complète.

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

ISO / IEC 12207 ne fournit pas de modèle de cycle de vie et 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 la relation entre les processus, les actions et les tâches effectué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 de cycle de vie du logiciel, 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 d'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, qu'il se compose de phases indépendantes, exécutées de manière séquentielle, et qu'il fait l'objet de 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 de manière suffisamment précise et complète afin de laisser aux développeurs la liberté de les mettre en œuvre le mieux possible d'un point de vue technique. .

Avantages du modèle itératif :

le modèle est bien connu des non-consommateurs de 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 des projets 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 remplir, 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 d'élaboration 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 ;

Au stade de la maintenance, le produit logiciel est révisé (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 soulignant les mots « oui » et « non ».

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

Équipe de développement... Sur la base des possibilités, la sélection du personnel pour l'équipe de développement a lieu avant même que le modèle de cycle de vie du développement logiciel ne soit choisi. 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 apporter une aide significative dans le choix d'un modèle de cycle de vie d'un 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 sa future relation avec l'équipe de développement tout au long du projet. Cette représentation 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, car 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 pour repré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 comptabilité 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 simplifiera le processus d'émission de 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, majoritairement des salarié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 :

Pour un usage interne dans une organisation ;

Un projet de mise en place d'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é d'entrer, de modifier et de stocker des informations sur les clients et les fournisseurs de l'organisation qui font l'objet de transactions à conclure ;

Un projet qui réalisera la formation de rapports externes.

4.3 Création d'une structure pour une liste d'œuvres étape par étape

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 exactement quel travail doit être fait pour obtenir son résultat. Ce n'est qu'après l'établissement d'une liste des travaux de conception que la durée de chacun d'eux est estimée et que les ressources nécessaires à leur mise en œuvre sont allouées. Et seulement alors, 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 d'un projet. La détermination de la portée des travaux 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, les phases de "Comptabilité d'inventaire" 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.

Après avoir déterminé la composition des phases et leurs résultats, il est nécessaire de déterminer l'enchaînement de ces phases les unes par rapport aux autres et les délais de leur mise en œuvre. Ensuite, vous devez déterminer de quels travaux se composent les phases, dans quel ordre ces travaux sont effectués et dans 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 étape par étape des travaux

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 des travaux étape par étape (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 de tâches verticalement. Dans ce cas, la longueur des segments désignant 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 qui y participent et leur chargement lorsque la tâche est terminée sont affichés).

Estimation du coût

Le projet consiste en 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 tarif basé sur le temps et le coût par utilisation.

Le taux basé sur le temps (Taux) est exprimé en 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 travaille dans le projet, multiplié par le taux horaire.

Dans ce cas, le taux de temps a été utilisé (Figure 4.4) Le coût total d'utilisation des ressources peut être vu sur 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 d'affaires reçoit 45 roubles de l'heure, un testeur 38 roubles de l'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 Affectation des ressources du projet

Un fragment de la répartition des ressources pour le système « Comptabilité d'inventaire » peut être vu dans la figure 4.6

Figure 4.6 - 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 l'efficacité économique du projet sera calculée. 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 pour laquelle le projet sera rentable.

Des données d'entrée.

Bénéfice supplémentaire du projet (DP) = 38 000 roubles. Le bénéfice supplémentaire a été prédit par les experts de l'entreprise.

Investissement initial (IC) = 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) = 12%.

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

Bénéfice supplémentaire du projet (DP) = 38 000 roubles.

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

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

Encaissements annuels (R 1) = 23 000 roubles.

Encaissements annuels (R 2) = 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 débiteur 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 - rentrées de fonds annuelles pendant n années.

k - le nombre d'années pour combien de temps le projet est conçu.

IC - investissement de démarrage.

i est le taux d'actualisation.

D'après les calculs de cette formule VAN = 3 460,67 roubles

La VAN est une augmentation absolue car elle estime à quel point la valeur actuelle chevauche le coût actuel. Puisque NPV> 0, le projet doit être accepté.

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

(4.3)

Calculé (ROI) = 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 = 1,84 an (1 an et 11 mois)

Puisque ROI => 100% (soit = ​​108,78%), le projet est considéré comme rentable.

(4.4)

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

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 assurer la planification des ressources de l'entreprise et la gestion de la production des commandes.

Exigences pour la fonctionnalité SI :

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

Maintenir des informations normatives et de référence sur la composition des GP avec la possibilité d'indiquer la période de pertinence du cahier des charges et avec la possibilité d'être en production de 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 :

Consulter l'historique des relations clients ;

Enregistrement/correction de la demande du client avec indication de la liste des entreprises publiques, des volumes, de la date d'expédition, du prix de vente et des éventuelles conditions supplémentaires ;

Afficher les indicateurs économiques actuels (estimations des 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 planifiée ;

Formation d'un plan de production avec une indication du 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-fait du plan de production ;

4. Gestion de production :

Formation de tâches postées (commandes) pour la fabrication de produits ;

Attribution/réattribution aux commandes des artistes interprètes ou exécutants et fixation de l'exécution des commandes avec indication du nombre de produits fabriqués, du nombre de produits défectueux et des motifs de la survenance du mariage ;

Gestion du stockage et du mouvement des articles d'inventaire (TMC) en production;

5. Gestion des approvisionnements :

Formation d'un bon de commande basé sur le plan des besoins en matériaux et composants, indiquant le fournisseur, la nomenclature des biens et des matériaux, la quantité et le délai de livraison ;

Formation de bons de commande sur la base de commandes ponctuelles de biens et de matériaux des départements ;

Contrôler et suivre le processus de réalisation des bons de commande ;

Contrôle opérationnel des résidus;

Analyse plan-fait des livraisons ;

6. Gestion des coûts :

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

Fixation des coûts réels de production ;

Calcul du coût réel de la SOE ;

Analyse des coûts planifiés et réels.

Conditions de 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 sur la composition standard de ce produit (spécification) et les prix comptables établis pour les articles en stock inclus dans cette spécification. Pour le cahier des charges, l'utilisation de plusieurs postes de coûts matériels 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 l'ouvrier requise pour cette opération, ainsi que le grade de l'ouvrier. En outre, le système introduit des taux monétaires d'heures standard pour les professions des 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 qu'il contient : quelles opérations doivent être effectuées et à quel moment. De plus, pour chaque opération, sont précisées la profession et la catégorie du travailleur, qui sont nécessaires à sa mise en œuvre (pour la libération de ce produit particulier) ;

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

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

Conditions de 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 matériaux pour la libération du produit sont calculés sur la base des données réelles sur la consommation de matériaux par le magasin pour les redistributions de la 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 clôture des commandes d'atelier. Dans le cas où les commandes ne sont pas enregistrées dans le SI, les salaires se réfèrent aux coûts directs soumis à répartition, c'est-à-dire répartis entre les produits manufacturés selon une certaine base.

3. L'amortissement des équipements directs de production 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 :

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

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

Amortissement du matériel direct si seul son montant mensuel total est disponible, sans ventilation par redistribution.

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

1. Frais généraux de production (compte 25 BU) : sont imputés aux produits manufacturés au prorata de la base de distribution choisie. La quote-part de ces dépenses peut ou non demeurer dans les travaux en cours conformément à la politique comptable adoptée dans l'entreprise.

2. Les frais généraux d'exploitation et 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 sans coupure des équipements techniques ;

2. Utilisation de logiciels sous licence ;

3. Mise en œuvre 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 de temps standard intersectorielles pour les travaux de maintenance des ordinateurs personnels et des équipements de bureau et la maintenance des logiciels » ;

4. Respect régulier des exigences de GOST 51188-98. "Protection des informations. Tester les logiciels pour détecter 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é.

1. Pertinence et nécessité de la recherche

Avec l'émergence récente en Fédération de Russie d'une nouvelle forme de gestion immobilière sous la forme d'associations de propriétaires (HOA), d'associations de propriétaires (HOA) et de copropriétés (ci-après - les organisations de gestion immobilière), les locataires (propriétaires) de logements ont une opportunité d'influencer la qualité de l'entretien des biens immobiliers, pour l'amélioration du territoire adjacent et dans une certaine mesure pour le coût des services publics.

Conformément à l'article 161 du Code du logement de la Fédération de Russie, la gestion d'un immeuble d'appartements doit garantir des conditions de vie favorables et sûres aux citoyens, un bon entretien des biens communs dans un immeuble d'appartements, résoudre les problèmes d'utilisation de cette propriété, ainsi que fournir des services publics aux citoyens vivant dans un tel bâtiment.

b) processus éducatif

Développement de cours scientifiques et pédagogiques, ainsi que de matériel de vulgarisation scientifique

	Nom du cours/ Matériel	Brève description du cours/ Matériel
Cours scientifiques et pédagogiques	Didacticiel "Systèmes d'information pour la gestion des immeubles à appartements"	Les capacités fonctionnelles des systèmes d'information pour la gestion immobilière utilisés dans la Fédération de Russie et à l'étranger sont présentées. Les capacités fonctionnelles sont comparées, des recommandations sont données sur le choix du système d'information. Il est destiné à enseigner aux étudiants dans les directions 080100.62 « Économie » et 080500.62 « Informatique de gestion »
Atelier de laboratoire "Système de gestion des règles métier d'une organisation pour la gestion de MKD"	Fournit des instructions pas à pas pour créer un module de gestion des règles métier à l'aide d'IBM ILog. Un algorithme de gestion des règles métier HOA est présenté. Conçu pour enseigner aux étudiants dans le sens 080500.62 "Business Informatics"
Atelier de laboratoire "Modélisation multi-agents des activités d'une organisation de gestion immobilière"	Fournit des instructions étape par étape pour la formation d'agents et la formation d'un modèle pour l'activité d'une organisation de gestion immobilière utilisant AnyLogic. Conçu pour enseigner aux étudiants dans la direction 080500.62 "Business Informatics"
Didacticiel "Développement d'une base de données d'immeubles d'appartements sous MS Access 2010"	Fournit des instructions pas à pas pour créer des tables de base de données, établir des liens entre elles, créer des formulaires, des requêtes, des rapports et des macros en utilisant les capacités du SGBD MS Access 2010.
Atelier de laboratoire "Analyse des processus d'affaires d'une organisation de gestion immobilière"	Les diagrammes développés à l'aide du langage de modélisation orienté objet UML sont présentés. Il est destiné à enseigner aux étudiants dans les directions 080100.62 « Économie » et 080500.62 « Informatique de gestion »
Matériel scientifique populaire	Monographie "Analyse factorielle et cluster des organisations régionales dans le domaine de la gestion immobilière"	Des recommandations pour l'analyse factorielle et en cluster des paramètres caractérisant le HOA de la région sélectionnée sont données. Fournit des informations sur les organisations de gestion immobilière avec les mêmes ensembles de processus métier et identifie les principaux facteurs affectant leurs activités
Monographie "Algorithmes pour l'échange d'informations dans une organisation de gestion immobilière"	L'algorithme général du fonctionnement du SI, des algorithmes pour le fonctionnement des modules logiciels du SI qui mettent en œuvre des services d'information pour les abonnés et des algorithmes pour l'interaction des modules logiciels sont présentés. Interfaces utilisateur du système d'information. Caractéristiques du développement de code de programme de modules à l'aide de l'environnement de développement MS Visual 2010
Article "Classification des abonnés et des systèmes d'information dans les organisations gérant MKD"	Les régularités de l'échange d'informations au sein d'une organisation de gestion immobilière, la composition et le volume de données attendus pendant l'échange d'informations, les transformations de données attendues pendant l'échange d'informations et les formes de présentation des données d'entrée et de sortie sont déterminées.
Article "Développement d'un modèle de simulation multi-agents pour modéliser les activités des associations de propriétaires"	Des approches à la formation d'agents pour le domaine, ainsi que le développement d'un modèle de simulation sont donnés. Les résultats de la modélisation des activités des associations de propriétaires avec différents ensembles de données initiales sont présentés.
Article "Formation d'un ensemble de règles commerciales pour les associations de propriétaires"	Des approches pour la formation d'un ensemble de règles métier sont données. Les possibilités de mise en œuvre d'un système de gestion des règles métier à l'aide d'IBM ILog sont envisagées. Un exemple d'utilisation de règles métier pour la prise de décision est donné.
Article "Formation d'algorithmes pour le système d'information d'une organisation de gestion immobilière"	La structure de l'algorithme du système d'information, la structure des algorithmes des modules logiciels qui mettent en œuvre des services d'information et l'échange d'informations avec la base de données de l'organisation sont pris en compte.
	Article "Application d'une approche holistique pour la formation d'un ensemble d'indicateurs de performance clés des activités HOA"	L'article considère l'application des dispositions d'une approche holistique pour former un ensemble d'indicateurs qui permettent la création d'un système d'évaluation de la réalisation des objectifs stratégiques et tactiques (opérationnels) d'une organisation de gestion immobilière, évaluant l'état de l'organisation et le suivi de l'activité commerciale des abonnés du système d'information en temps réel.
Article "Services d'information pour la gestion des immeubles à appartements"	Les services d'information fournis par des systèmes d'information étrangers aux propriétaires (locataires) de biens immobiliers dans des immeubles à appartements sont pris en compte.
Article "Formation d'une base de données pour le système d'information de la HOA"	L'article examine les modèles de données, la technologie de stockage et de traitement des données, la composition des données, les formats de données pour la réflexion dans les interfaces utilisateur et les documents de sortie, les types de données, la composition attendue des tableaux, ainsi qu'un diagramme des relations entre les tableaux.
Article "Analyse organisationnelle et modèle de processus métier de HOA"	Le développement d'un ensemble de modèles est envisagé : un modèle d'établissement d'objectifs stratégiques, un modèle organisationnel-fonctionnel, un modèle fonctionnel-technologique, un modèle de rôle-processus d'un modèle quantitatif, un modèle de structure de données (sous quelle forme la réglementation HOA et les objets de l'environnement externe sont décrits), les modèles de processus métier

Sur la base de l'objectif du système d'information en cours de développement, nous continuerons à concevoir la structure modulaire de l'application. Pour définir la structure modulaire, nous utiliserons le diagramme de composants de notation UML 2.0 (Figure 3.4).

Riz. 3.4

Le système d'information est composé de trois éléments :

• 1. Interfaces. Mise en place de l'interaction utilisateur avec le système d'information. Contient les modules suivants :
  • · Entrée/sortie - organisation de l'entrée et de la sortie des informations lorsque l'on travaille avec le SI ;
  • · Reporting - organisation du reporting conformément aux formulaires de documentation établis pour les différents domaines de l'agence de recrutement ;
  • · Recherche - organiser la recherche de candidats et de postes vacants selon les paramètres spécifiés ;
• 2. Traitement des données. Mise en œuvre de fonctions de traitement de l'information : recherche de données dans une base de données, d'un modèle mathématique pour la tâche d'analyse primaire de documents, etc. ;
• 3. BD. Implémentation d'un magasin de données qui contient des informations sur les clients.

Conception de la structure de la base de données

Comme mentionné précédemment, dans le système d'information, toutes les informations sont stockées dans une seule base de données. La méthodologie IDEF1x a été appliquée pour modéliser la structure logique de la base de données. Selon cette méthodologie, le processus de construction d'un modèle d'information comprend les étapes suivantes :

• · Définition des entités ; définir les dépendances entre les entités ;
• · Attribution des clés primaires et alternatives ;
• · Définition des attributs des entités ;
• · Amener le modèle au niveau requis de forme normale;
• · Passage à la description physique du modèle : affectation des correspondances nom entité - nom table, attribut entité - attribut table ;
• · Attribution de déclencheurs, de procédures et de restrictions ;
• · Génération de base de données.

Le diagramme entité-relation décrivant la base de données en termes d'IDEF1.x est construit à partir de trois blocs principaux - entités, attributs et relations. Si nous considérons un diagramme comme une représentation graphique des règles du domaine, alors les entités et les attributs sont des noms et les relations sont des verbes.

Étant donné que le futur SI de cette base de données recherchera, les éléments suivants ont été choisis comme principaux attributs du document :

• - le nom du document ;
• - la date de réception du document dans les archives (les cabinets d'avocats qui fournissent des services d'archivage surveillent la durée de conservation de la documentation. Chaque document a sa propre durée de conservation. De nombreux titres perdent de leur pertinence avec le temps, et leur valeur est réduite à zéro. les documents doivent être détruits. La sélection en temps opportun de ces documents et la destruction des documents sont incluses dans l'ensemble des services d'archivage fournis par les cabinets d'avocats. Lors de l'acceptation pour le stockage, chaque document, après un examen spécial, est déterminé par la période de stockage. Après cette période , le document est soumis pour destruction);
• - appartenance (type) du document (puisque tous les documents ont été divisés en 7 types, pour lesquels le classement a été fait par ordre d'importance) ;
• -numéro de colonne ;
• - numéro d'étagère ;
• - numéro de traîneau (ces 3 paramètres sont nécessaires pour déterminer l'emplacement du document dans l'archive) ;
• - la présence d'un document dans sa cellule (il faut savoir si le document est dans les archives, ou s'il a été délivré au demandeur).

Le résultat d'une requête pour sélectionner tous les documents appartenant à un client doit ressembler à ceci, voir Figure 3.5. Dans l'exemple présenté, le nombre de documents a été volontairement limité à 20.

Considérons maintenant plus en détail le modèle de données logique du système d'information en cours de développement, illustré à la figure 3.6.

Riz. 3.5

Riz. 3.6

À partir du modèle de données présenté, on peut voir qu'il contient trois entités, chacune avec son propre ensemble d'attributs, dont deux sont dépendants et un ne l'est pas.

L'entité « Employé », qui est une entité indépendante, possède les attributs suivants :

• · Numéro d'identification de l'employé - est la clé primaire de cette entité ;
• · Nom complet de l'employé;
• · Domaine de spécialisation;
• · Évaluation;
• · Informations Complémentaires.

L'entité Client est une entité dépendante de l'entité Employé, ce qui signifie que chaque employé peut servir de nombreux clients. L'entité cliente a des attributs :

• · Série et numéro de passeport - est la clé primaire de cette entité ;
• · Numéro d'identification de l'employé - est la clé secondaire de cette entité ;
• · Nom complet de l'employé;
• · Domaine de spécialisation;
• · Évaluation;
• · Informations Complémentaires.

L'entité « Document » est une entité dépendante de l'entité « Client », ce qui signifie que chaque client peut stocker de nombreux documents différents dans l'archive. L'entité document a les attributs suivants :

• · Identificateur de document - est la clé primaire de cette entité ;
• · Série et numéro de passeport - est la clé secondaire de cette entité ;
• · Nom du document ;
• · Date de réception;
• · Appartenance à un groupe ;
• · Numéro de colonne ;
• · Numéro d'étagère ;
• · Numéro du traîneau;
• · La présence du document dans la cellule.

Créé à partir de nombreux modules Système d'Information a permis à l'usine automobile de Nijni Novgorod "Chaika-Service" de mettre en œuvre l'idée de production qui prend pleinement en compte les souhaits des clients qui ont passé leurs commandes à l'entreprise

Le système d'information créé à partir de divers modules a permis à l'usine automobile de Nijni Novgorod "Chaika-Service" de mettre en œuvre l'idée de production, qui prend pleinement en compte les souhaits des clients qui ont passé leurs commandes dans l'entreprise

Le principal défi pour le service informatique d'une entreprise en activité en ces temps difficiles est de réduire les coûts informatiques et de fournir à la direction les outils pour l'aider à traverser la crise. C'est l'avis d'Aleksey Ganin, chef du département informatique de l'usine automobile de Nijni Novgorod "Chaika-Service", spécialisée dans la production de véhicules spéciaux en série et uniques.

L'entreprise a connu une croissance rapide en 2006, lorsqu'une partie de l'ancienne usine a été acquise et le développement du deuxième territoire a commencé. Naturellement, la tâche s'est posée d'unir les deux territoires en un seul champ d'information. Nous avons commencé par la création d'un réseau VPN, mais à mesure que le nombre d'utilisateurs augmentait, la bande passante du canal commençait à être insuffisante. Puis un câble de fibre optique a été posé entre les deux territoires.

Avec le début de la crise, le besoin en ressources réseau a diminué, ce qui a permis de réduire l'achat d'équipements actifs pour l'infrastructure de télécommunications de l'entreprise. Une autre source importante de réduction des coûts a été l'abandon de l'externalisation et la mise en œuvre de tâches informatiques en interne.

De plus, l'entreprise optimise les coûts Internet, analyse et limite la consommation de trafic. La société a des succursales à Krasnodar et à Moscou, tous les sites sont réunis dans un réseau IP avec une seule numérotation. Et maintenant, pour les appels au sein de l'entreprise, ils utilisent ce réseau interne particulier, qui est beaucoup plus économique que les appels via la communication téléphonique longue distance.

Parmi les outils qui seront fournis à la direction dans un avenir proche, Ganin a nommé tout d'abord le système de calcul des coûts. Il a déjà été développé et servira l'objectif global global de réduction des coûts. Il est prévu que le calcul affiné du coût des marchandises soit effectué sur la base du système de gestion des données d'ingénierie. Celui-ci fournira des données détaillées et opérationnelles sur le prix de revient (auparavant ils étaient calculés sur la base de données comptables). L'entreprise fabrique des produits assez complexes, seules les variantes finales de voitures avec diverses modifications sont d'environ un millier et demi. Naturellement, les pièces à partir desquelles ils sont assemblés sont de deux ordres de grandeur de plus.

De la comptabilité à la production

Le premier pas vers l'automatisation a été l'acquisition en 2002 du produit 1C : Comptabilité 6.0 et du système de CAO Compass d'Ascon. L'étape suivante était l'automatisation des activités de production. La société "Rarus NN", à la demande de l'entreprise, a commencé à adapter le système ERP "1C: Manufacturing Enterprise Management 8" ("1C: UPP 8") aux besoins et aux caractéristiques de l'entreprise. L'objectif du projet était de construire une base de données unifiée et de mettre en œuvre la gestion de tous les processus métier sur la base d'un système d'information unifié. Un facteur décisif dans le succès de sa mise en œuvre a été le soutien direct de la haute direction de l'entreprise - le directeur général, qui a initié et soutenu le projet à toutes ses étapes.

Lors de l'automatisation des activités de production, une attention particulière a été accordée à l'adéquation de l'affichage dans le système du processus de production. Les spécialistes de l'équipe de mise en œuvre ont développé une tâche technique avec une description détaillée du type de voiture dans quelle configuration le client doit recevoir et de ce qui doit être fait pour cela pour chaque commande. Le type de voiture, son modèle, une liste des opérations technologiques requises, leur séquence, une liste des opérations de contrôle, etc. étaient inscrits dans le document. Cette approche a permis d'orienter davantage l'entreprise vers le client, puisque les spécifications techniques ont été formées par les responsables du service commercial, qui ont essayé de prendre en compte au maximum les souhaits du client, et alors seulement les tâches ont été envoyé en production.

Les spécialistes du service informatique, en collaboration avec les technologues, ont élaboré un bloc de spécifications pour la production et les cartes technologiques. Sur leur base et sur la base du plan mensuel de sortie des produits finis, le besoin en matériaux pour une certaine période a été déterminé, en tenant compte des soldes actuels. Tout cela a permis de planifier avec compétence le travail du service d'approvisionnement.

Les employés du service informatique ont développé un module pour "1C: UPP 8" pour importer un "arbre" d'un produit du système "Compass", qui est utilisé par les concepteurs de l'entreprise. L'algorithme de travail s'est avéré le suivant : le bureau d'études développe un dessin au moyen de "Compass" et crée un modèle 3D de l'objet, puis la structure du produit est importée dans le système ERP à l'aide du module développé, après quoi une spécification de produit est construit sur la base des données importées. Si les concepteurs apportent des modifications à un nœud, ces modifications sont automatiquement répercutées dans tous les systèmes.

Au début, comme l'a admis Ganin, lui et ses spécialistes voulaient créer eux-mêmes un système de gestion des données d'ingénierie, mais ils ont rapidement découvert que le groupe de sociétés Appius, partenaire de 1C, développait sa propre solution PDM réplicable (c'était appelé 1C : PDM Engineering data management").

Retour d'information

La tâche suivante était d'obtenir un retour d'expérience opérationnel de la production, c'est important, car le cycle technologique de fabrication d'un produit peut prendre une à deux semaines. Auparavant, le statut de la commande était connu simplement par téléphone, mais maintenant, les informations pertinentes sont reçues au moyen du système d'information.

Le premier pas dans cette direction a été l'élaboration d'un système de suivi de l'état des termes de référence. Certains processus de production ont été modifiés, en particulier, les employés du service de contrôle de la qualité ont été obligés de soumettre des rapports sur les travaux acceptés à l'opérateur et il a saisi les données les concernant dans le système ERP. En conséquence, le système a commencé à afficher le passage d'un ordre de fabrication par étapes avec une indication des personnes responsables, ce qui a permis aux gestionnaires de fournir aux clients des informations véridiques sur l'étape à laquelle se trouvent leurs commandes et quand elles seront prêtes.

L'étape suivante a été la mise en œuvre du module de planification de la production. Auparavant, la planification était réalisée à l'aide d'outils Excel, il y avait souvent des incohérences et des erreurs. Après le lancement du module ERP de planification de la production, les responsables ont reçu les données réelles à leur disposition, qui ont été formées sur la base des spécifications techniques reçues. Cela a permis de suivre rapidement le chargement de chaque section. En conséquence, la précision et l'efficacité de la planification de la production ont augmenté.

Bientôt, il y avait un besoin d'informations plus opérationnelles sur l'état des processus de production, en particulier sur les temps d'arrêt. Pour résoudre ce problème, un système permettant de suivre l'avancement des processus de production basé sur le code-barres a été mis en place : chaque opération technologique, chaque tâche technique et chaque employé s'est vu attribuer un code-barres, et des terminaux équipés d'un lecteur de codes-barres ont été installés dans le production.

Le processus de production est maintenant structuré comme suit. Avant de commencer le travail, un contremaître ou un ouvrier s'approche du terminal, lit son code-barres, le code-barres de la mission technique et de l'opération technologique. Du point de vue du système, cela signifie que l'employé a commencé à travailler. Après son achèvement, l'employé répète ses actions avec des codes à barres.

« C'est une solution à guichet unique, et elle n'exige pas que les travailleurs maîtrisent l'informatique », explique Ganin. - La voiture étant le composant principal et le plus coûteux de notre production, la réduction des temps d'arrêt nous a permis d'accélérer considérablement l'exécution des commandes. Un outil pratique et simple d'analyse des pertes est apparu dans l'entreprise : le système génère automatiquement des diagrammes de travail pour chaque voiture, vous permettant de suivre quand le travail a commencé sur une voiture donnée, quand il s'est terminé, combien de temps la voiture est restée en attente du suivant. opération. Lorsque le temps autorisé est dépassé, l'identification des raisons et la recherche des coupables d'un temps d'arrêt aussi long commencent. En conséquence, la responsabilité personnelle des artistes interprètes ou exécutants s'est accrue.

Sur la base de "1C: UPP 8", les spécialistes de l'entreprise ont mis en place une unité de planification pour le travail d'un bureau d'études. Les tâches techniques créées dans le système reviennent au concepteur en chef, qui les analyse, répartit leur élaboration entre ses concepteurs et détermine le temps de chaque tâche. Cette organisation du travail donne au chef concepteur et aux gestionnaires, qui constituent la base de commande, la possibilité de suivre la charge de travail du bureau d'études, ce qui permet à son tour de comparer la charge de travail de la production et des concepteurs et d'allouer rationnellement les ressources humaines et moyens de production.

Les données sur le travail effectué, obtenues grâce aux codes-barres, sont transmises à l'unité de calcul des salaires des artistes interprètes. Le système enregistre le temps de travail, ce qui facilite le calcul des week-ends et des heures supplémentaires. Tout cela contribue à un calcul de paie rapide et précis.

Il est important de souligner que l'entreprise a suivi la voie de l'expansion

La configuration de base du système ERP avec des blocs supplémentaires, sans modifier sa structure interne. Il devenait possible, notamment, d'effectuer ses mises à jour sans problème.

Pour gérer les archives de la documentation de conception, la société a mis en œuvre le système de gestion des données d'ingénierie 1C : PDM (développé par le groupe de sociétés Appius) et l'a intégré à 1C : UPP 8. En plus du travail sur la création de nouveaux produits, le système de gestion des données d'ingénierie devrait être utilisé pour calculer plus précisément le coût des produits.

Intégration à multiples facettes

L'entreprise a mis en place une navigation GPS pour suivre les véhicules de ravitaillement et les véhicules de transport de marchandises qui parcourent de longues distances. Cela nous permet d'optimiser les itinéraires, de réduire les coûts de carburant et de maintenir plus précisément la discipline des approvisionnements.

Chaika-Service prévoit de relier toutes les succursales en un seul réseau via des systèmes de vidéoconférence - deux à Nijni Novgorod et un à Moscou, Krasnodar et Naberezhnye Chelny. Ainsi, l'efficacité de la prise de décision par le top management s'améliorera et les coûts financiers et temporels des déplacements professionnels seront considérablement réduits.

« Nous prévoyons également de mettre en œuvre une solution basée sur 1C : UPP 8 pour l'interaction avec la police de la circulation, la préparation et l'impression des numéros d'immatriculation des véhicules et de transit », note Ganin. - Toutes les données seront regroupées en un seul endroit pour stocker les informations - une carte de voiture, où tous ses numéros d'identification, couleur, numéro de carrosserie, etc. seront saisis, puis ces données seront utilisées dans les termes de référence, lors de l'impression du titre du véhicule, numéros, certificats, factures". Une telle intégration donnera aux clients de l'entreprise la possibilité de recevoir des numéros d'immatriculation et de transit prêts à l'emploi avec la voiture, de sorte qu'il sera possible d'enregistrer rapidement les voitures auprès de la police de la circulation.