Définition du modèle de cycle de vie ais. Modèles de cycle de vie AIS. Schémas de conception en cascade et en spirale pour AIS. Forces et faiblesses Cycle de vie AIS et modèles de cycle de vie

3.1 Définir un modèle de cycle de vie AIS

Un modèle de cycle de vie de développement de produit logiciel est compris comme une structure qui détermine la séquence d'exécution et les interrelations des processus, des actions et des tâches effectuées tout au long du cycle de vie de développement du produit logiciel. Les modèles de cycle de vie de développement de produits logiciels suivants sont les plus largement utilisés (tableau 1. Brèves caractéristiques Modèles de cycle de vie AIS) : modèle en cascade, ou cascade (modèle en cascade) ; modèle en forme de V (modèle en forme de V); modèle de prototypage (modèle prototype); modèle de développement rapide d'applications, ou modèle RAD (modèle de développement rapide d'applications RAD), modèle multi-passes (modèle incrémental); modèle en spirale.

Tableau 1. Brèves caractéristiques de chacun des modèles répertoriés

Nom	les caractéristiques
Modèle en cascade	Simple et facile à utiliser. Un contrôle strict et constant de l'avancement des travaux est nécessaire. Le logiciel développé n'est pas disponible pour modification
modèle en V	Facile à utiliser. L'accent est mis sur les tests et la comparaison des résultats des phases de test et de conception
Modèle de prototypage	Une implémentation partielle "rapide" du système est créée avant l'élaboration des exigences finales. Fournit des commentaires entre les utilisateurs et les développeurs dans le processus de mise en œuvre du projet. Les exigences utilisées ne sont pas complètes
Modèle de développement rapide d'applications	Les équipes de projet sont petites (3…7 personnes) et sont composées de spécialistes hautement qualifiés. Réduction du temps de cycle de développement (jusqu'à 3 mois) et amélioration des performances. Réutilisation du code et automatisation du processus de développement
Modèle multipasse	Un système de travail est rapidement créé. Réduit la possibilité d'apporter des modifications au cours du processus de développement. Il n'est pas possible de passer de l'implémentation actuelle à nouvelle version lors de la construction de l'implantation partielle actuelle
modèle en spirale	Couvre le modèle de cascade. Décompose les phases en parties plus petites. Permet une conception flexible. Analyse et gère les risques. Les utilisateurs se familiarisent plus tôt avec le produit logiciel grâce aux prototypes

3.2 Modèle en cascade

Dans les systèmes d'information homogènes des années 1970 et 1980, les produits logiciels d'application constituaient une seule entité. Pour développer ce type de produit logiciel, un modèle en cascade, ou « cascade », a été utilisé.

Le modèle en cascade d'un produit logiciel est similaire au modèle d'un système de contrôle automatisé (voir Chapitre 1, Fig. 1).

Ce processus est, en règle générale, de nature itérative : les résultats étape suivante entraînent souvent des changements dans les décisions de conception prises à des stades antérieurs. Ainsi, il y a un besoin constant de revenir aux étapes précédentes et de clarifier ou de réviser les décisions prises précédemment. En conséquence, le processus de développement proprement dit prend une forme différente (voir chapitre 1, figure 2)

Modèle 3,3 V

Ce modèle (Fig. 5) a été développé comme une variante du modèle en cascade, dans lequel une attention particulière est accordée à la vérification et à la validation du produit logiciel. Le modèle montre que les tests de produits sont discutés, conçus et planifiés tôt dans le cycle de vie du développement.

Du modèle en cascade, le modèle en forme de V a hérité d'une structure séquentielle, selon laquelle chaque phase suivante ne commence qu'après la réussite de la phase précédente.

Ce modèle est basé sur une approche systématique du problème, pour laquelle quatre étapes de base sont définies : analyse, conception, développement et révision. L'analyse implique la planification et les exigences du projet. La conception est divisée en haut niveau et détaillée (bas niveau). Le développement comprend le codage, la révision - différentes sortes essai.

Le modèle montre clairement la relation entre les phases d'analyse et les phases de conception qui précèdent le codage et les tests. Les flèches en pointillés indiquent que ces phases doivent être considérées en parallèle.

Le modèle comprend les phases suivantes :

Exigences de conception pour le projet et la planification - les exigences du système sont déterminées et la planification des travaux est effectuée ;

Préparation des exigences pour le produit et leur analyse - une spécification complète des exigences pour le produit logiciel est compilée ;

Conception de haut niveau - la structure est définie Logiciel, la relation entre ses composants principaux et les fonctions qu'ils mettent en œuvre ;

Conception détaillée - l'algorithme de fonctionnement de chaque composant est déterminé ;

Codage - la transformation des algorithmes en logiciel fini est effectuée;

Tests unitaires - chaque composant ou module du produit logiciel est testé ;

Tests d'intégration - l'intégration du produit logiciel et ses tests sont effectués ;

Test du système - le fonctionnement du produit logiciel est vérifié après son placement dans l'environnement matériel conformément à la spécification des exigences ;

Exploitation et maintenance - lancement d'un produit logiciel en production. Au cours de cette phase, le produit logiciel peut être modifié et mis à jour.

Fig.5 Modèle en V

Avantages du modèle en V :

1) Un grand rôle est accordé à la vérification et à la certification du produit logiciel, dès les premières étapes de son développement, toutes les actions sont planifiées ;

2) L'attestation et la vérification non seulement du produit logiciel lui-même, mais également de toutes les données internes et externes reçues sont supposées ;

3) L'avancement des travaux peut être facilement suivi car l'achèvement de chaque phase est une étape importante.

En plus de ces avantages, le modèle présente également un certain nombre d'inconvénients :

les itérations entre phases ne sont pas prises en compte ; il est impossible d'apporter des modifications aux différentes étapes du cycle de vie ; les tests d'exigences se produisent trop tard, donc apporter des modifications affecte le calendrier.

Il est opportun d'utiliser ce modèle dans le développement de produits logiciels, dont la principale exigence est une fiabilité élevée.

Le produit et la création de fiches pratiques pour renseigner les attributs de la base de données : la simplicité de création des liens et leur modernisation. Chapitre II. Développement d'un programme d'automatisation des activités de la flotte de taxis 2.1 Analyse des besoins des clients Programme automatisé lieu de travail taxi dispatcher est développé selon le modèle en spirale du cycle de vie des systèmes d'information automatisés. A chaque étape de la création...

Systèmes. Principale documents normatifs, réglementant le processus de création de tout projet SI et informatique, sont les GOST et leurs complexes pour la création et documenter informatique, systèmes automatisés, logiciels, organisation et traitement des données, ainsi que les documents constitutifs de la Commission technique d'État de Russie sur le développement, la fabrication et l'exploitation de logiciels et ...

Sujet 1.2 Cycle de vie AIS et modèles de cycle de vie AIS

Cycle de vie AIS -c'est un processus continu à partir du moment où une décision est prise sur la nécessité de prendre une décision sur la nécessité de sa création jusqu'à l'achèvement complet de son fonctionnement.

Le cycle de vie de l'AIS moderne est d'environ 10 ans, ce qui dépasse largement l'obsolescence et l'obsolescence physique des logiciels techniques et système utilisés dans la mise en œuvre de l'AIS. Par conséquent, en règle générale, pendant le cycle de vie du système, sa modernisation est effectuée, après quoi toutes les fonctions du système doivent être exécutées avec non moins d'efficacité.

Y parvenir tout au long du cycle de vie de l'AIS est une tâche assez difficile pour un certain nombre de raisons objectives et subjectives, par conséquent, la grande majorité des projets AIS sont mis en œuvre avec des violations de la qualité, des délais ou des estimations ; près d'un tiers des projets cessent d'exister inachevés. Selon le Standish Group en 1996, 84% des projets AIS n'étaient pas achevés à temps, en 1998 ce nombre est tombé à 74%, après 2000 il ne tombe pas en dessous de 50%. raison principale Cette situation est que le niveau de technologie pour analyser et concevoir des systèmes, des méthodes et des outils de gestion de projet ne correspond pas à la complexité des systèmes en cours de création, qui ne cesse d'augmenter en raison de la complexité et changement rapide des affaires.

Il est connu de la pratique mondiale que le coût de maintenance du logiciel d'application AIS représente au moins 70 % de son coût total tout au long du cycle de vie, il est donc extrêmement important de fournir les méthodes et moyens de support nécessaires, y compris les méthodes de gestion de la configuration, même à l'étape de conception.

Le processus de conception AIS est régi par la documentation suivante (normes, méthodologies, modèles) :

GOST 34.601-90- une norme pour les étapes et les étapes de création d'AIS, correspondant au modèle en cascade du cycle de vie du logiciel (abordé ci-dessous). Une description du contenu des travaux à chaque étape est donnée ;

180/1CE 12207:1995- norme de processus et d'organisation du cycle de vie ; s'applique à tous les types de logiciels personnalisés ; ne contient pas de description des phases, étapes et étapes ;

Méthode de développement personnalisée(Méthodologie Oracle) - matériel technologique sur le développement d'AIS appliqués, détaillés au niveau des blancs des documents de projet basés sur l'utilisation d'Oracle. Il est utilisé pour le modèle classique du cycle de vie (tous les travaux, tâches et étapes sont fournis), ainsi que pour " développement rapide" (Fast Track) ou technologies "approche légère", recommandées pour les petits projets.

processus unifié rationnel(méthodologie RUP) - matériel technologique pour la mise en œuvre d'un modèle de développement itératif, qui comprend quatre phases (cycle de développement): initiation, recherche, construction et mise en œuvre. Chaque phase est divisée en étapes (itérations) dont les résultats sont des versions à usage interne ou externe. Chaque cycle se termine par la génération de la prochaine version du système. Si après cela, le travail sur le projet ne s'arrête pas, le produit résultant continue de se développer et traverse à nouveau les mêmes phases. L'essentiel du travail dans le cadre de la méthodologie RUP est la création et la maintenance de modèles basés sur UML ;

Cadre de solution Microsoft(méthodologie MSF) - le matériel technologique pour la mise en œuvre d'un modèle de développement itératif, similaire au RUP comprend quatre phases : analyse, conception, développement, stabilisation ; implique l'utilisation de la modélisation orientée objet. MSF se concentre davantage sur le développement d'applications métier que RUP ;

Programmation extrême (XP)- la programmation extrême (la plus récente parmi les méthodologies envisagées) ; a été formé en 1996. La base de la méthodologie est le travail d'équipe, une communication efficace entre le client et l'entrepreneur tout au long du projet ; le développement de l'AIS est réalisé à l'aide de prototypes successivement raffinés.

La norme ISO/IEC 12207 dans le cadre du cycle de vie définit les processus qui sont exécutés lors de la création d'un logiciel AIS. Ces processus sont divisés en trois groupes :

principale(acquisition, fourniture, développement, exploitation et maintenance) ;

auxiliaire(documentation, gestion de la configuration, assurance qualité, vérification, validation, évaluation, audit et résolution de problèmes) ;

organisationnel(gestion de projet, création d'infrastructure de projet, définition, évaluation et amélioration du cycle de vie lui-même, formation).

Parmi processus principaux cycle de vie les plus importants sont développement, exploitation et accompagnement. Chaque processus est caractérisé par certaines tâches et méthodes pour les résoudre, les données initiales obtenues à l'étape précédente et les résultats.

Développement AIS comprend tous les travaux de création de logiciels et de ses composants conformément aux exigences spécifiées. Ce processus comprend également :

Préparation de la documentation de conception et d'exploitation ;

Préparation du matériel nécessaire pour tester les produits logiciels développés ;

Élaboration du matériel nécessaire à la formation du personnel.

Généralement, les composants du processus de développement sont planification stratégique, analyse, conception et réalisation (programmation).

Procéder exploitation relater:

Configuration de la base de données et des postes utilisateurs ;

Fournir aux utilisateurs une documentation opérationnelle ;

Formation.

Les principales activités opérationnelles comprennent :

Opération directe ;

Localisation des problèmes et élimination de leurs causes ;

modification de logiciel ;

Préparation de propositions d'amélioration du système ;

Développement et modernisation du système.

Professionnel, compétent escorte- condition nécessaire résoudre des tâches effectuées par AIS. Prestations de service soutien technique jouer un rôle très important dans la vie de tout AIS. Les erreurs à ce stade peuvent entraîner des pertes financières évidentes ou cachées comparables au coût du système lui-même.

Aux actions préalables à l'organisation Maintenance L'AIS comprend :

Identification des nœuds les plus critiques du système et détermination de la criticité des temps d'arrêt pour eux (cela nous permettra d'identifier les composants les plus critiques de l'AIS et d'optimiser l'allocation des ressources pour la maintenance) ;

Définition des tâches de maintenance et leur division en interne, résolue par les forces du service après-vente, et externe, résolue par des organisations de service spécialisées (ainsi, l'éventail des fonctions exercées est clairement limité et la responsabilité est répartie);

Procéder à une analyse des ressources internes et externes disponibles nécessaires à l'organisation de la maintenance dans le cadre des tâches décrites et de la répartition des compétences (les principaux critères d'analyse : la disponibilité d'une garantie pour le matériel, l'état du fonds de réparation, les qualifications du personnel);

Préparation d'un plan d'organisation de la maintenance avec la définition des étapes des actions à effectuer, le calendrier de leur exécution, les coûts aux étapes, la responsabilité des exécutants.

Assurer une maintenance de haute qualité de l'AL nécessite l'implication de spécialistes hautement qualifiés capables de résoudre non seulement les tâches administratives quotidiennes, mais également de restaurer rapidement les performances du système en cas de pannes et d'accidents.

Parmi processus de soutien l'un des principaux est gestion de la configuration, qui prend en charge les principaux processus du cycle de vie AIS, principalement les processus de développement et de maintenance.

Le développement d'AIS complexes implique le développement indépendant des composants du système, ce qui conduit à l'émergence de nombreuses options et versions de mise en œuvre des composants individuels et du système dans son ensemble. Ainsi, il y a un problème d'assurer la préservation d'une structure unique lors du développement et de la modernisation de l'AIS. La gestion de la configuration permet d'organiser, de prendre en compte et de contrôler systématiquement les évolutions des différents composants de l'AIS à toutes les étapes de son cycle de vie.

Processus organisationnels sont d'une grande importance, car les AIS modernes sont de grands complexes, dans la création et la maintenance desquels de nombreuses personnes de différentes spécialités sont employées.

Processus (exécuteur de processus)	Actions"	Entrée	Résultat
Acquisition (client)	Initiation. Préparation des propositions de candidature. Préparation du contrat. Contrôle de l'activité des fournisseurs. Acceptation AIS	La décision de commencer à travailler sur la mise en œuvre de l'AIS. Les résultats d'une enquête sur les activités du client. Résultats de l'analyse du marché AIS/appel d'offres. Plan de livraison/développement. Test AIS complet	Étude de faisabilité pour l'introduction de l'AIS. Termes de référence pour l'AIS. Contrat de fourniture/développement. Actes de réception d'étapes de travail. Rapport de test d'acceptation
Livraison (développeur AIS)	Initiation. Réponse aux appels d'offres. Préparation du contrat. Planification de l'exécution. Fourniture d'AIS	Termes de référence pour l'AIS. La décision de la direction de participer au développement. tendres résultats. Termes de référence pour l'AIS. Plan de gestion de projet. Développement de l'AIS et de la documentation	La décision de participer au développement. Offres commerciales/soumission. Contrat de fourniture/développement. Plan de gestion de projet. Mise en œuvre/ajustement. Rapport de test d'acceptation
Développement (développeur AIS)	Formation. Analyse des exigences pour l'AIS. Conception de l'architecture AIS. Développement des exigences logicielles. Conception d'architectures logicielles. Conception détaillée du logiciel. Codage et test de logiciels. Intégration de logiciels et tests de qualification de logiciels. Intégration SI et tests de qualification AIS	Termes de référence pour l'AIS. Termes de référence pour AIS, modèle de cycle de vie. Termes de référence pour l'AIS. sous-systèmes AIS. Spécifications des exigences pour les composants logiciels Architecture logicielle Matériaux pour la conception détaillée du logiciel Plan d'intégration logicielle, tests Architecture du SI, logiciel, documentation du SI, tests	Modèle de cycle de vie utilisé, normes de développement. Plan de travail. La composition des sous-systèmes, des composants de l'équipement. Spécifications des exigences pour les composants logiciels. La composition des composants logiciels, les interfaces avec la base de données, le plan d'intégration du logiciel. Conception de la base de données, spécifications d'interface entre les composants logiciels, exigences de test. Tests de modules logiciels, actes de tests autonomes. Évaluation de la conformité du complexe logiciel aux exigences des TDR. Évaluation de la conformité des logiciels, de la base de données, du complexe technique et de la documentation avec les exigences des TDR

La gestion de projet est liée aux problématiques de planification et d'organisation du travail, de constitution d'équipes de développeurs, de suivi des délais et de la qualité des travaux. Le support technique et organisationnel du projet comprend :

Choix des méthodes et des outils de mise en œuvre du projet ;

Définition des méthodes de description de l'état du processus de développement ;

Développement de méthodes et de moyens de test des logiciels créés ;

Formation.

L'assurance qualité de la conception est liée aux problèmes de vérification, de vérification et de test des composants AIS.

Vérification - le processus consistant à déterminer si l'état actuel de développement atteint à un stade donné répond aux exigences de ce stade.

Examen- le processus de détermination de la conformité des paramètres de développement avec les exigences initiales. La vérification chevauche quelque peu les essais, qui sont effectués pour déterminer les différences entre les résultats réels et attendus, ainsi que pour évaluer la conformité des performances de l'AIS avec les exigences initiales.

En 2002 Une norme pour les processus du cycle de vie des systèmes automatisés (ISO/IEC 15288 System Life cycle process) a été publiée. Des spécialistes de divers domaines Activités; l'expérience pratique dans la création de systèmes au sein d'organisations gouvernementales, commerciales, militaires et universitaires a été prise en compte. Selon la série ISO/IEC 15288, les groupes de processus suivants sont inclus dans la structure LC.

1. Processus contractuels :

Acquisition (solutions internes ou solutions de prestataires externes) ;

Livraison (solutions internes ou solutions d'un fournisseur externe).

2. Processus d'entreprise :

Contrôler environnement entreprises;

Gestion des investissements; dans la gestion du cycle de vie de la propriété intellectuelle ;

La gestion des ressources;

Contrôle de qualité.

3. Processus de conception :

Planification de projet ;

Evaluation de projet;

Le contrôle du projet;

Gestion des risques ;

Gestion de la configuration;

Gestion des flux d'informations ;

Faire des décisions.

4. Processus techniques :

Définition des besoins ;

Analyse des besoins;

Développement architectural ;

la mise en oeuvre;

L'intégration;

Vérification;

Passage;

Attestation ;

Exploitation;

Escorte;

Disposition.

5. Procédés spéciaux :

Définition et établissement des interrelations à partir des tâches et des finalités.

En tableau. 1.4 montre la liste des étapes et les principaux résultats au moment où ils sont terminés conformément à la norme spécifiée.

Dans les années 1970 IBM a proposé la méthodologie Business System Planning (BSP) ou méthodologie de planification organisationnelle.

Une méthode de structuration de l'information utilisant des matrices d'intersection des processus métier, des divisions fonctionnelles des systèmes de traitement de données (SI), des objets d'information, des documents et des bases de données, des propositions dans BSP, leur séquence (obtenir le support de la haute direction, définir les processus d'entreprise, définir les processus, les classes de données , apporter des entretiens, traiter et organiser les données d'entretien) se retrouvent dans presque toutes les méthodes formelles, ainsi que dans les projets mis en œuvre dans la pratique.

Tableau 1.4.Étapes de création AIS (ISO/IEC 15288)

Selon les données publiées, chaque étape du développement de l'AIS nécessite un certain temps. La plupart du temps (45-50%) est consacré au codage, complexe et test hors ligne(Fig. 14). En moyenne, le développement de l'AIS prend un tiers du cycle de vie complet du système (Figure 1.5).

Fig.1.4. Répartition du temps dans le développement de l'AIS

Description de la présentation Etapes de création des modèles AIS du cycle de vie des AIS par diapositives

Le cycle de vie de l'AIS est un ensemble d'étapes et d'étapes que l'AIS traverse dans son développement à partir du moment où la décision est prise de créer un système jusqu'au moment où il cesse de fonctionner.

Étapes du cycle de vie 1 Planification et analyse (étape d'avant-projet) - déterminer ce que le système doit faire. Enregistrement d'une étude de faisabilité (étude de faisabilité) et des termes de référence (TOR).

2 Conception (conception technique et logique) – définition du fonctionnement du système (spécification* des sous-systèmes, des composants fonctionnels et de leur interaction). Inscription projet technique. * Spécification - une description précise, complète et clairement articulée des exigences pour une tâche donnée.

3. Mise en œuvre (conception détaillée, programmation) - Création de composants fonctionnels et de sous-systèmes séparés, connexion des sous-systèmes en un seul ensemble. Remplissage de la base de données. Création d'instructions pour le personnel. Réaliser une ébauche de travail

4 Mise en œuvre (tests, fonctionnement d'essai) - installation et mise en service du système, débogage des sous-systèmes, formation du personnel. Enregistrement de l'acte de tests d'acceptation.

Remarques 1. Les étapes 2 et 3 peuvent être combinées en une seule : conception techno-détaillée ou synthèse du système. 2. A chaque étape du cycle de vie, un certain ensemble de solutions techniques et de documents associés sont utilisés

3. Pour chaque étape, les documents et décisions prises à l'étape précédente sont les premiers. 4. Les modèles de cycle de vie déterminent l'ordre d'exécution des étapes du processus de création d'un système et les critères de passage d'une étape à l'autre.

Le modèle de cycle de vie est un modèle de création et d'utilisation d'AIS, qui reflète les différents états du système depuis le moment de sa création jusqu'au moment où il est complètement hors d'usage.

Les principaux modèles du cycle de vie Cascade - implique le passage à l'étape suivante après l'achèvement de la précédente. Ce modèle est utilisé dans la construction de l'AIS pour lequel toutes les exigences sont précisément et complètement formulées dès le début. Inconvénients: schéma rigide - impossibilité de revenir aux étapes précédentes et utilisation pour des systèmes complexes.

Modèle itératif pas à pas Rétroaction entre cycles. L'avantage est que les ajustements inter-étages offrent plus de flexibilité et moins d'effort. L'inconvénient est que la durée de vie de chacune des étapes peut s'étendre sur toute la période de création du système Difficultés et inconvénients du modèle en spirale du cycle de vie Le principal problème est la détermination du passage à l'étape suivante : pour le résoudre , des délais sont introduits pour chacune des étapes. La transition s'effectue conformément au plan établi sur la base des données statistiques des projets précédents et de l'expérience des développeurs. Inconvénients : Les erreurs commises lors des phases d'analyse et de conception peuvent entraîner des problèmes dans les phases suivantes et l'échec de l'ensemble du projet.

Le rôle d'utilisateur AIS est créé pour répondre aux besoins d'information d'un utilisateur particulier. Il est directement impliqué dans ses travaux. .

L'utilisateur participe à la formulation du problème et effectue une opération d'essai, au cours de laquelle il peut détecter des lacunes dans la formulation, corriger la saisie et informations de sortie, des formulaires pour la publication des résultats et des documents.

La participation des utilisateurs à la création d'AIS permet une résolution rapide et de haute qualité des problèmes, réduit le temps nécessaire à l'introduction de nouvelles technologies

Introduction

1. Architecture des systèmes d'information automatisés et problèmes de son amélioration 13

1.1. Modèles d'architecture et principaux composants de l'AIS 13

1.2. Problèmes de développement AIS 47

1.3. Plates-formes pour la mise en œuvre de la nouvelle architecture de l'AIS UP 53

1.4. Chapitre 1 Conclusions 57

2. Modèle d'architecture AIS UE 58

2.1. Exigences de base pour AIS UP 59

2.2. Architecture AIS UP 66

2.3. Composants AIS UP 89

2.4. Chapitre 2 Conclusions 102

3. Méthodes de mise en œuvre pratique de l'AIS UE 104

3.1. Outils de développement AIS UP 104

3.2. Expérience dans la mise en œuvre pratique du modèle AIS UP 111

3.3. Chapitre 3 Conclusions 123

4. Conclusion 125

5. Terminologie et abréviations 128

6. Littérature

Introduction au travail

Activité entreprises modernes associés au mouvement de flux interdépendants et volumétriques de matières, de capitaux, de main-d'œuvre et ressources d'information. La gestion des processus du cycle de production et de commercialisation dans un environnement politique et économique en constante évolution nécessite une prise de décision rapide dans court instant. La solution à ce problème en conditions modernes est impossible sans le recours à un traitement automatisé d'informations techniques et économiques.

Au cours des 40 dernières années, les technologies de l'information (TI) automatisées ont été activement utilisées pour résoudre les problèmes de comptabilité, de planification et d'analyse activité économique entreprises de diverses formes de propriété, d'affiliation à l'industrie, de structure organisationnelle et d'échelle d'activité. Pendant ce temps, une grande expérience pratique a été accumulée dans la création de systèmes d'information automatisés pour la gestion d'entreprise (AIS UE), des méthodologies de gestion ont été développées et ont reçu une reconnaissance universelle, dont l'application est impossible en dehors de l'environnement informatique. On peut dire en toute responsabilité qu'AIS UE est devenu une partie intégrante de l'infrastructure de l'entreprise. Les problèmes théoriques et pratiques de l'automatisation des processus économiques sont étudiés en profondeur dans les travaux de Glushkov V.M., Volkov S.I., Isakov V.I., Ostrovsky O.M., Podolsky V.I., Ratmirov Yu.A., Romanov A.N. , Hotyashova E.N., Brady R., Zachman J. , Cook M., Finkelstein K., Hammer M. et d'autres auteurs. Les approches proposées par eux sont devenues la base de l'utilisation de la technologie informatique dans les entreprises pour résoudre les problèmes de comptabilité, de planification et d'analyse des activités financières et économiques. Cependant

les modèles qu'ils proposaient ne tenaient pas compte des réalités de l'économie de la société de l'information et du niveau actuel de développement informatique.

Le développement des moyens de communication contribue à une interaction toujours plus étroite entre producteurs et consommateurs, fournisseurs et acheteurs, accroît la concurrence sur le marché, étend les frontières des marchés locaux aux marchés nationaux et transnationaux et accélère le temps des transactions économiques et des transactions financières. L'introduction des réseaux informatiques mondiaux dans les processus économiques a conduit à l'émergence de nouveaux concepts : l'économie de la société de l'information, commerce électronique(e-business), commerce électronique (e-commerce), électronique parquet(marché électronique);

Les concepts existants d'organisation AIS UE sont basés sur une approche fonctionnelle de la répartition des tâches entre ses sous-systèmes. Cependant, l'AIS, construit comme un complexe de sous-systèmes centrés sur des fonctions de gestion individuelles, ne répond pas au mieux à l'exigence de continuité des processus métier de bout en bout d'une entreprise. Par conséquent, ces dernières années, une approche est devenue de plus en plus populaire, dans laquelle les processus métier sont mis au premier plan, et non les fonctions individuelles des services du système de gestion qui les exécutent. Cela nécessite le développement d'un nouveau concept d'architecture AIS UE. Dans le même temps, il est évident que la transition vers une nouvelle architecture AIS UE ne peut pas être effectuée immédiatement, car au fil des ans, les entreprises et les organisations ont mis en service un grand nombre d'outils logiciels qui mettent en œuvre la solution de tâches de gestion importantes. , dont l'usage ne peut être abandonné immédiatement. Malheureusement, la plupart d'entre eux sont axés sur un fonctionnement autonome, ce qui complique considérablement l'intégration complexe des flux d'informations. De nombreux produits logiciels existants qui permettent de résoudre les nouveaux problèmes de gestion d'entreprise apparus dans le contexte de la mondialisation de l'économie sont également développés sans élaboration suffisante d'interfaces d'interaction avec complexes logiciels, réalisant la solution des problèmes connexes. Dans ces conditions, la tâche de synthétiser des systèmes intégrés de gestion d'entreprise en intégrant des composants tiers prêts à l'emploi, des solutions sur mesure et des développements internes revêt une importance particulière.

L'idée de mettre en œuvre des normes d'intégration système pour les outils logiciels fournis par divers fabricants a longtemps été discutée dans les publications de scientifiques et de praticiens. Les progrès des outils système ont conduit à l'émergence de technologies de développement de logiciels orientés objet et composants qui vous permettent de construire des systèmes à grande échelle à partir de blocs prêts à l'emploi. Principaux fournisseurs de matériel et de logiciels système (Intel, Microsoft, Sun, Oracle, IBM, etc.), d'outils de communication (Cisco, Nortel, Ericsson, Motorola), de solutions appliquées (SAP, PeopleSoft, Siebel, etc.), d'État faisant autorité, internationales, commerciales et associations à but non lucratif et associations (ISO, IEEE, ASCII, APICS, RosStandard, etc.) ont désormais développé et mettent activement en pratique des technologies d'intégration de matériel et de logiciels permettant de créer des systèmes ouverts basés sur des normes et des protocoles pour l'échange de données et l'interaction des composants dans un environnement hétérogène en mode temps réel.

Cependant, ces propositions ne fournissent qu'une plate-forme à l'échelle du système, ce qui nécessite un raffinement significatif par rapport à un domaine spécifique. Dans le cadre de la mise en œuvre pratique de l'AIS UE, mécanismes de conception et de développement de systèmes d'information (SI) utilisant des architectures multi-liens à composants basés sur des standards et des protocoles systèmes ouverts pas assez travaillé.

A cet égard, le problème de l'élaboration d'une plate-forme théorique et de l'élaboration conseils pratiques visant à construire AIS UE, fournissant une automatisation complète de toutes les procédures d'information pour la gestion des entreprises et des organisations.

La nécessité de développer une approche holistique pour résoudre les problèmes d'intégration de système d'AIS PM et d'automatisation de bout en bout des processus microéconomiques basés sur l'informatique moderne a déterminé le choix du sujet et l'orientation de cette étude.

L'objectif de l'étude est de développer un modèle de l'architecture AIS UE qui fournit une automatisation complète et un support d'information pour les processus commerciaux de bout en bout, et de justifier le choix des outils pour son intégration de système du point de vue de la modernité. technologies de l'information.

Sur la base de l'objectif visé, les tâches scientifiques et pratiques suivantes ont été définies et résolues :

Analyser et généraliser les approches existantes pour la conception, le développement et la mise en œuvre du logiciel AIS UP ;

Classer les types de logiciels utilisés dans la pratique de la gestion d'entreprise;

Explorer les technologies et les normes existantes qui permettent l'intégration d'outils logiciels hétérogènes ;

Identifier les problèmes qui surviennent lors de l'intégration des outils logiciels utilisés dans AIS UE ;

Systématiser les exigences fixées par les entreprises pour que le logiciel AIS UE fournisse un support d'information pour les processus économiques de bout en bout ;

Développer un modèle d'architecture AIS UE et mettre en évidence ses principaux composants ;

Développer les principes d'interaction et d'échange de données des composants AIS UE ;

L'objet de la recherche porte sur les méthodes et les outils de développement des systèmes d'information économique.

L'objet de l'étude est le SI de gestion d'entreprise.

La méthodologie de recherche est basée sur des applications spécifiques de la méthodologie de la connaissance scientifique dans les domaines appliqués de l'informatique et des mathématiques.

Les buts et objectifs de l'étude ont été formulés conformément à l'orientation principale des travaux sur le développement et l'amélioration ultérieurs méthodes mathématiques et la technologie informatique utilisée dans les domaines économiques.

Parallèlement à une approche scientifique générale basée sur la théorie des systèmes, la thèse résume l'expérience de développement, de mise en œuvre et d'exploitation d'outils logiciels de fabricants nationaux et étrangers, de méthodes

mise en œuvre de normes internationales ouvertes pour les systèmes d'information du bâtiment. Sur cette base, un ensemble de recommandations méthodologiques et pratiques sont proposées qui ont été testées dans des entreprises russes et étrangères.

L'article utilise les dispositions théoriques des œuvres d'auteurs nationaux et étrangers dans le domaine de:

Traitement automatisé d'informations économiques et modélisation de processus économiques;

Méthodologies de planification et de gestion opérationnelle de la production et des stocks ;

Réingénierie et conception informatique des processus d'affaires;

Normes modernes en technologie de l'information.

L'étude a analysé et utilisé les développements réalisés par des équipes de recherche et des scientifiques individuels de l'Académie financière du gouvernement de la Fédération de Russie, de l'Institut panrusse de correspondance des finances et de l'économie, de l'Université d'État d'économie, de statistique et d'informatique de Moscou, de l'Université de Saint-Pétersbourg. d'économie et des finances. Voznesensky, Research Financial Institute et d'autres organisations.

La base d'informations de l'étude comprenait des produits logiciels de fabricants russes et étrangers, des publications dans des publications économiques et informatiques, des recherches menées par des groupes de recherche internationaux Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest, etc. matériel pédagogique principales sociétés nationales et internationales de conseil et d'audit, résultats de recherche de l'Association des développeurs de logiciels dans le domaine de l'économie,

étude du marché des logiciels en Russie et dans les pays de la CEI TSIES "Business-Programs-Service" .

La nouveauté scientifique de la thèse réside dans le développement d'un modèle d'architecture AIS UE axé sur l'automatisation intégrée des processus métier de bout en bout, et des propositions pour sa mise en œuvre par l'intégration système d'outils logiciels hétérogènes dans un environnement de réseau hétérogène distribué basé sur technologies d'objets et de composants.

La nouveauté scientifique contient les résultats suivants obtenus dans la thèse :

Définition et classification des exigences pour la fonctionnalité du logiciel de gestion organisationnelle et économique des entreprises ;

Modèle d'architecture AIS UE axé sur l'automatisation intégrée des processus métier de bout en bout ;

Principes d'intégration d'outils logiciels pour résoudre les problèmes des services fonctionnels d'une entreprise avec un logiciel de base pour la gestion des processus métier, l'échange de données et la gestion des documents ;

Propositions d'organisation d'un espace d'information unique de l'entreprise, accessible aux salariés et partenaires de l'entreprise via le portail web de l'entreprise ;

Propositions de mise en œuvre système unifié formation et classification des rapports à l'aide d'outils analytiques;

Principes de mise en œuvre de l'interaction des sous-systèmes AIS UE basés sur des technologies orientées objet et composants et l'interaction des composants logiciels dans un réseau distribué

environnement conforme aux normes de l'industrie et aux protocoles Internet ;

Un mécanisme pour mettre en œuvre les propriétés adaptatives du modèle d'architecture du logiciel AIS PM conformément aux exigences d'une entreprise particulière, basé sur la capacité de configurer les sous-systèmes de base aux processus de travail existants et projetés.

L'importance pratique du travail de thèse est que la mise en œuvre des propositions proposées vous permet de créer AIS UE, fournissant un soutien efficace aux procédures d'information pour la gestion des activités d'une entreprise dans le contexte d'une économie mondialisée et la formation d'une société de l'information.

Le modèle d'architecture AIS UE proposé et les recommandations pour son application ont une flexibilité et une polyvalence suffisantes, ce qui garantit leur applicabilité dans la gestion des systèmes d'information d'entreprises de diverses formes de propriété, spécificités de l'industrie et échelle d'activité.

Indépendant valeur pratique avoir:

Propositions pour la sélection et l'application des normes, protocoles et autres mécanismes utilisés dans l'intégration du système AIS UE ;

Offres pour automatisation intégrée processus métier et flux de travail de bout en bout ;

Propositions de création d'un espace d'information unique de l'entreprise utilisant le mécanisme des portails web ;

Propositions d'adaptation de l'approche itérative en spirale dans le développement et la mise en œuvre du logiciel AIS UP.

L'importance pratique du travail a été évaluée dans des projets spécifiques pour la mise en œuvre du modèle orienté problème proposé d'un système d'automatisation d'entreprise :

Système de gestion d'entreprise intégré "Flagman" de la société "Infosoft",

les systèmes de gestion de la relation client eRelationship de Pivotal Software Corporation (Canada),

Systèmes de reporting d'entreprise Monarch ES de DataWatch (USA),

Le projet d'intégration des systèmes d'information des sociétés Sovintel et Tele Ross.

Le centre de formation Vest-MetaTechnology utilise du matériel préparé par l'auteur sur la base de l'approche proposée au cours de cette étude lors de la conduite de cours sur le développement de systèmes d'information de gestion d'entreprise (voir http://www.vest.msk.ru).

Le matériel de recherche de thèse est utilisé dans la recherche et activités pratiques organes exécutifs de l'Association of Software Developers in Economics (AREP) et de ses membres.

Les principales dispositions de l'ouvrage ont été rapportées et discutées à :

Conférence "Solutions IBM dans le domaine de l'intégration commerciale pour les entreprises de télécommunications", bureau de représentation d'IBM en Europe de l'Est (Moscou, 18 juin 2002);

Symposium "Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management" (Moscou, mars 2002);

Conférences de développeurs de systèmes d'information basés sur les outils de la société Centura Software Corp. (Berlin, Allemagne, 17-19 novembre 1999) ;

Conférence "InfoCity : pratique et problèmes d'informatisation des villes" (Moscou, octobre 1999) ;

Conférences scientifiques et pratiques de la société "Infosoft" (Moscou, 1995-1999);

Conférences de spécialistes dans le domaine des ACS et CIS "Corporate Systems" (Moscou, avril 1998 et 28-30 avril 1997, organisateurs : société SoftService et bureaux de représentation d'Oracle, Informix, Sybase, Borland et Centura) ;

3e conférence annuelle "Corporate databases 98" (Moscou, 31 mars-3 avril 1998 et 26-29 mars 1996, organisée par le Centre des technologies de l'information avec la participation de la maison d'édition Open Systems);

Conférence "Tekhnikom-97" (Moscou, 24-26 novembre 1997, organisateurs : SoftService, Association russe utilisateurs d'Oracle, bureaux de représentation de Microsoft, Borland, Computer Associates, Lucent Software).

Problèmes de développement AIS

L'introduction des technologies de l'information dans l'économie, la pénétration des outils informatiques et de communication dans la gestion des entreprises à tous les niveaux, l'intérêt croissant pour l'interaction des entreprises via Internet nécessitent des changements conceptuels dans les approches de construction de l'AIS UE. Cela concerne non seulement les problèmes purement technologiques de création et d'exploitation des SI, mais aussi les approches de la gestion d'entreprise dans l'économie de la société de l'information.

AIS UE doit répondre aux besoins d'automatisation et d'informatisation de l'ensemble de l'organisation, ce qui confie aux développeurs de logiciels la tâche de : développer une plate-forme capable de prendre en charge le travail d'un grand nombre d'utilisateurs ; prise en charge des outils de communication et des normes de l'industrie pour les protocoles d'échange de données et d'interaction des composants ; l'intégration des développements existants dans un système unique.

L'intégration d'applications hétérogènes au sein d'un AIS unique doit prendre en charge : les processus métier de bout en bout ; interface utilisateur unique (portail); espace d'information commun.

À notre avis, l'essence des problèmes posés ne réside pas tant dans les aspects techniques de la mise en œuvre, mais dans la nécessité d'utiliser un modèle fondamentalement nouveau d'architecture AIS UE.

Résumons les avantages et les inconvénients des différentes options d'architecture SI en termes de possibilités de construction d'une solution intégrée.

La centralisation du traitement des données impose des exigences élevées aux serveurs. Avec une augmentation du nombre d'utilisateurs simultanés (ce qui est inévitable lors de l'automatisation des processus dans toute l'entreprise), les charges deviennent excessives pour la plate-forme matérielle et les logiciels utilisés. En utilisant diverses solutions matérielles (clustering, multitraitement et autres formes de combinaison de ressources informatiques), ainsi que le traitement distribué à l'aide de moniteurs de transactions, de serveurs d'applications et de puissants SGBD industriels, vous pouvez créer des solutions véritablement évolutives, déchargeant les nœuds centraux non seulement en augmentant la puissance de matériel, mais aussi en raison de la construction appropriée des composants logiciels du système.

Cependant, même si le serveur de base de données central est capable de fournir les performances requises, avec une telle construction du SI, des problèmes surviennent inévitablement pour maintenir une structure unique de la base de données générale si des composants logiciels individuels du SI sont développés. différentes entreprises ou même des équipes de développement au sein de la même organisation. L'installation d'une base de données commune avec accès à partir de programmes pour résoudre divers problèmes appliqués permet de fournir un espace d'information commun, les technologies énumérées ci-dessus permettent à un grand nombre d'utilisateurs d'accéder à la base de données, mais cela ne garantit pas un travail correct avec des données partagées. Reste le problème de l'intégrité logique des données. Lors de l'utilisation de programmes de différents fabricants, il devient inévitable de séparer les données en sous-systèmes, éventuellement en les dénormalisant et en créant des structures redondantes. L'architecture de base commune est illustrée schématiquement dans la figure suivante (Figure 1-14). Comme il ressort du schéma ci-dessus, les modules n'interagissent pas, c'est-à-dire qu'il n'y a pas d'appel d'un module à l'autre en temps réel, il n'y a pas de support opérationnel pour un processus de bout en bout. Les données sont stockées dans la base de données, à partir de laquelle elles sont disponibles pour d'autres modules qui doivent contenir les fonctions de suivi des modifications, et la pertinence des données dépend de la fréquence de vérification des mises à jour. Un exemple de processus de bout en bout serait une facturation par un employé du service commercial. S'il utilise un système CRM pour cela, la facture générée doit être traitée en parallèle avec le relevé dans le module logistique du système ERP pour réserver la marchandise, et immédiatement après cela - dans le module financier pour augmenter la dette de l'acheteur. Pour ce faire, les modules concernés doivent vérifier l'existence d'un nouveau compte. Si cela n'est pas fait dans les délais, une facture pourra être émise pour l'article effectivement réservé.

Pour que différents modules fonctionnent avec une structure de base de données commune, ils doivent initialement être développés en vue d'une structure de données spécifique ou utiliser un mécanisme de métadonnées convenu (référentiel).

Lors de l'utilisation d'une architecture différente, lorsque des bases de données hétérogènes sont maintenues sur différents ordinateurs (et, éventuellement, sur différents réseaux) et utilisées par des modules autonomes (Figure 1-15), le maintien de l'intégrité logique des données est une tâche encore plus chronophage . Dans ce cas, il est nécessaire de réglementer et de mettre en œuvre la réplication des données (synchronisation), l'unification des répertoires, les règles de codage et de classification, de développer ou de mettre en œuvre le mécanisme de réplication lui-même. Tout cela nécessite des mesures organisationnelles pour synchroniser la base de données. Reste le problème de la poursuite automatique du processus (un exemple avec une facture).

Plates-formes pour la mise en œuvre de la nouvelle architecture AIS UE

Au début du 21e siècle, les solutions suivantes ont été développées et maîtrisées au niveau industriel dans l'industrie informatique, ce qui a assuré l'introduction généralisée de l'informatique dans les processus économiques :

outil informatique personnel, consistant dans le fait que dans de nombreux types de travail, le besoin d'intermédiaires entre l'énoncé de tâche et son exécuteur a disparu, c'est-à-dire que les employés des services fonctionnels de l'entreprise sont en mesure d'effectuer ceux qui relèvent de leur compétence procédures d'information utiliser des ordinateurs sans la participation ou avec un soutien minimal du personnel technique accompagnateur ;

des moyens de support automatisé pour le travail conjoint coordonné d'un groupe ("équipe") d'employés sur un projet, un document, une tâche, etc. ;

mécanisme de communication électronique, qui dans de nombreux cas a permis d'éliminer la nécessité de transférer des documents papier, de minimiser le besoin de réunions, ce qui est particulièrement important lorsque les participants à un processus métier particulier sont géographiquement éloignés.

Grâce à ces solutions, il est devenu possible d'automatiser la plupart des processus de travail intervenant tant au sein de l'entreprise dans ses activités financières, économiques, productives et commerciales, que liés aux fonctions externes. La combinaison d'outils logiciels et matériels qui automatisent diverses fonctions et postes de travail permet de lier les processus technologiques (basés sur l'équipement et les dispositifs techniques) et les processus de travail (avec la participation d'employés de tous les départements des entreprises) dans des processus commerciaux de bout en bout . Ainsi, il existe une possibilité fondamentale de résoudre le problème de l'isolement des points d'origine des données des centres de leur stockage et de leur traitement, la séparation des lieux de travail les uns des autres.

Résoudre le problème de l'intégration des modules AIS et choisir une approche centralisée ou décentralisée pour organiser leur interaction est également possible grâce aux derniers développements des principaux fabricants de logiciels système : systèmes d'exploitation, serveurs web, serveurs d'applications, SGBD et plateformes middleware. L'intégration d'applications est rendue possible grâce à l'utilisation d'une technologie de développement orientée objet et d'une architecture multiniveau basée sur des composants. Le principe clé ici est le concept d'interfaces de programmation et les règles pour les modifier et les étendre (IDL).

Pour travailler dans un environnement hétérogène distribué, tel qu'Internet, des spécifications de services Web sont activement développées, chacune pouvant mettre en œuvre une ou plusieurs procédures ou fonctions métier (procédures métier, fonctions). OASIS, BPMI et IBM, Microsoft et BEA ont publié les spécifications de régulation des workflows BPEL4WS (Business Process Execution Language for Web Services), XLANG et WSFL (Web Services Flow Language), et la coalition WfML - XPDL (XML Process Definition Language) .

La tendance est de combiner des composants avec des interfaces de service Web ouvertes dans des sous-systèmes qui exécutent des cycles de processus métier logiquement complets. Dans ce cas, les composants peuvent être situés sur différents serveurs d'applications répartis sur le réseau et fonctionner avec une ou plusieurs bases de données. En faisant varier le nombre et les relations des composants, le nombre et l'emplacement des serveurs réseau, la possibilité de remplacer des composants ou de les déplacer sur le réseau sans perte de compatibilité, il est possible de construire un AIS qui maintient un équilibre entre centralisation et décentralisation dans l'entreprise le management.

Il n'y a pas d'obstacles techniques à la mise en place d'une telle architecture. Les serveurs d'applications industriels modernes (par exemple, MTS / COM + / .Net, ONE ou J2EE / EJB) vous permettent de créer des systèmes multiniveaux, de fournir une plate-forme commune pour accéder à divers services Web, d'assurer l'intégrité transactionnelle des opérations, l'équilibrage de charge avec un accès compétitif à des dizaines de milliers d'utilisateurs en temps réel, ainsi qu'une garantie de tolérance aux pannes et de récupération après les pannes.

Une réalisation importante de l'industrie informatique sont les normes qui se sont généralisées et reconnues par les principaux fabricants de logiciels : protocoles d'interaction des composants (COM/DCOM, CORBA, Java RMI) et formats d'échange de données (EDI, XML,).

La norme EDI et ses variantes industrielles (EDIFACT, XI2, HIPAA, etc.) sont utilisées dans les secteurs financier et industriel d'Amérique du Nord et d'Europe depuis le milieu des années 1970 et dominent aujourd'hui dans le monde entier. Avec la popularité croissante du XML sur Internet, l'EDI a été traduit en XML.

Sur la base de XML (DTD et XDR), des données ont été développées, structurées et formatées dans divers domaines économiques sous la forme de soi-disant dictionnaires thématiques ou de types de documents, par exemple WIDL, OFX, FpML, IFX, XBRL, CRML et de nombreux autres en Occident, ainsi que CommerceML.ru et XML Partnership/ARB en Russie. L'American Society for Production and Inventory Management APICS, qui certifie les systèmes de classe ERP/MRP, publie les spécifications des entités économiques au format XML, par exemple la structure et le format des données client ou de facturation. XML auto-documenté fournit une compréhension sans ambiguïté des données par les humains et les programmes.

Architecture de l'UE AIS

Pour construire un modèle d'architecture AIS UE, nous considérerons une entreprise comme un ensemble de ressources humaines, financières, matérielles et informationnelles impliquées dans les processus métier pour atteindre les objectifs commerciaux d'une entreprise. Ici, le terme objectifs commerciaux fait référence aux objectifs stratégiques à long terme définis par les propriétaires et les cadres supérieurs, ainsi qu'aux objectifs actuels assignés par les cadres supérieurs et intermédiaires. Un processus métier ou un processus métier est une séquence d'actions d'employés, d'opérations sur les lieux de travail, ainsi que de fonctions exécutées par des logiciels et moyens techniques en mode automatique. Appelons chaque action ou leur séquence une étape du processus. Les synonymes d'actions peuvent également être des opérations, des procédures. Si une étape nécessite les actions d'un employé (un groupe de rôles, un représentant ou un chef de service, ainsi qu'une personne occupant un poste officiel), elle est également appelée tâche et l'employé est appelé exécuteur. La séquence d'actions dans un processus métier peut être ambiguë, c'est-à-dire que la description du processus sous la forme d'un graphe orienté peut inclure des branchements avec des conditions de passage d'une étape à une autre. Les chaînes typiques d'étapes peuvent être divisées en sous-processus. Le mouvement des tâches par étapes spécifiées du processus est appelé un itinéraire. Si le processus ne peut pas être décrit en raison de transitions arbitraires entre les étapes, dont la décision est prise par l'exécutant lors de l'exécution de la tâche à l'étape actuelle, ce cas est appelé routage libre.

AIS PM doit permettre de décrire formellement les processus métier sous forme graphique sous la forme d'un graphe orienté (digraphe), dont les sommets sont les étapes, et les arêtes sont les transitions entre les étapes. Dans un cas particulier, le graphe de processus métier ressemble à un graphe de réseau, où les sommets représentent les travaux avec leur durée, et les arêtes orientées (flèches) montrent la séquence des travaux. Conformément à la description du processus, appelée schéma de processus, AIS UE doit gérer les ressources (ou, plus précisément, aider les responsables de l'entreprise à les gérer), attribuer des tâches et leurs exécuteurs, et également appeler (activer) des logiciels et du matériel. exécuter des procédures automatisées.

Les paramètres de l'échelle de l'entreprise affectent l'organisation de la gestion dans une entreprise particulière, ce qui se reflète dans les exigences de l'AIS UE. D'autre part, AIS UE affecte l'échelle de l'entreprise, par exemple, en contribuant à la croissance de l'entreprise. La modification d'un des paramètres entraîne une mise à jour de l'AIS au même titre que l'introduction de l'AIS peut modifier l'organisation de la gestion.

L'objectif de se concentrer sur les processus métier lors de la construction de l'AIS UE est de trouver une plate-forme commune sur la base de laquelle il sera possible de modifier adéquatement l'AIS sans nécessiter une réorganisation complète du système. Cette plateforme est la modélisation des processus métiers par un logiciel de gestion de processus.

En tant que cœur de l'AIS PM, il est nécessaire de développer un système qui combine plusieurs fonctions abordées dans la revue des systèmes de gestion des processus (paragraphes "1.1.7 Systèmes de gestion des documents" en page 31 et "1.1.8 Systèmes de gestion des processus" en page 34). Parmi eux : Workflow - un sous-système de gestion du travail et des processus technologiques qui fournit un routage prédéfini et libre des tâches entre les interprètes ; Docflow - un sous-système de gestion du flux de documents et de routage des documents avec suivi de leurs états ; Groupware - un sous-système pour prendre en charge les fonctions d'attribution opérationnelle des tâches et de routage libre (ad hoc) des tâches entre les membres d'un groupe d'interprètes; Flux de données - données de routage, paquets de données, messages entre applications.

Contrairement à la pratique admise d'utilisation autonome de tels systèmes, nous supposons ici la présence d'une carte de processus commune, d'un module commun de traitement des étapes du processus, d'un mécanisme commun d'affectation d'exécuteurs et de routage des tâches et des données.

Ainsi, les données technologiques générées par les dispositifs techniques, les données factuelles saisies dans le SI par les utilisateurs sur les lieux de travail (y compris les documents primaires), ainsi que les données générées par les applications logicielles, seront saisies dans l'AIS UE et mises à la disposition des consommateurs d'informations en temps réel. .

Schématiquement, le cycle de vie du traitement des données dans AIS UE est présenté dans la figure suivante (Figure 2-2). Les données saisies manuellement ou reçues des composants logiciels sont formalisées sous la forme d'un document, qui est ensuite traité par le module de flux de travail conformément à la carte de processus. Le long de la voie de traitement (si la configuration du système l'exige), le sous-système de gestion des documents appelle les modules des sous-systèmes fonctionnels pour le traitement des transactions financières, commerciales et autres. Par conséquent, les informations d'identification sont stockées dans des bases de données structurées. À leur tour, les documents eux-mêmes sont stockés dans un stockage ou une base de données non structurée. Toutes ces bases de données doivent être disponibles pour les modules analytiques du sous-système de reporting afin de générer les rapports nécessaires.

Expérience dans la mise en œuvre pratique du modèle AIS UE

De 1995 à 1999, sous la direction de l'auteur de la thèse, le système d'automatisation de gestion d'entreprise intégrée "Flagman" de la société "Infosoft" a été développé, qui est actuellement mis en œuvre dans plus d'une centaine de grandes et moyennes entreprises industrielles, entreprises de construction, commerciales, agricoles et organisations budgétaires Russie et pays de la CEI. Le système continue de se développer sur la base du noyau développé par l'auteur et, en 2002, le "Flagship" comprend plus de dix sous-systèmes principaux, illustrés dans la figure suivante (Figure 3-2):

La base du système "Flagman" est le module de base "Document Management", qui est responsable de la saisie, du traitement, de l'acheminement et de l'impression de tous documents primaires. Les autres modules de base sont "Administration" et "Outils", communs à tous les modules fonctionnels. Ils vous permettent de configurer des groupes de rôles et des droits d'accès, des postes de travail jusqu'aux éléments de menu, des mises en page de documents et des modèles de rapport.

Les avantages du modèle mis en place étaient une saisie unique des documents primaires, la génération comptes dans les sous-systèmes fonctionnels basés sur ces documents, unification du travail avec les documents primaires.

Le développement rapide des sous-systèmes et le manque de standardisation de leur interaction a conduit au fait que l'intégration s'est faite autour d'une base de données centrale et de tables communes. Si l'on ne tient pas compte de l'architecture à deux niveaux, dont le choix a été déterminé par le niveau de développement des outils de développement en 1995, alors l'interdépendance des modules est devenue le principal problème pour le développement du système. Ses premières implémentations ont révélé l'insuffisance des fonctions d'automatisation des workflows par le seul routage des documents et ont posé la question de la nécessité d'implémenter un module de gestion des processus (workflow).

Si nous considérons l'implémentation plus en détail, le module de gestion de documents est une bibliothèque d'objets inclus dans tous les sous-systèmes, et également compilé en tant que module autonome. La bibliothèque comprend des outils de paramétrage de types et de variantes de documents, de composition de champs, de formulaires de saisie et d'édition, une liste d'états, des combinaisons possibles de transitions d'état à état, une liste d'opérations faisant référence à des modules fonctionnels, des modèles et des impressions formulaires, ainsi que les règles de constitution des registres et journaux de documents .

Les opérations avec des documents changent leur état et appellent également les fonctions des sous-systèmes d'application. La liste des fonctions est intégrée à chaque sous-système et lui est propre. Pour les programmeurs accompagnateurs impliqués dans la configuration du système, des paramètres de fonction et la possibilité de leur lier des champs de document à l'aide de formules sont disponibles. Cela vous permet d'automatiser la plupart des transactions financières, ainsi que les fonctions logistiques, dossiers du personnel et la paie, mais la mise en œuvre complète nécessite toujours un langage de script.

Le système dispose d'un générateur de rapports intégré commun à tous les sous-systèmes. Le système étant basé sur le principe de l'intégration autour d'une base de données centrale, le générateur a accès à toutes les données, qu'elles appartiennent ou non à des modules. Les rapports sont classés en structure hiérarchique, chacune des présentations de rapport contient un modèle pour Aperçu et l'impression, et des requêtes SQL pour générer l'ensemble de données résultant. Les rapports générés peuvent ensuite être traités comme des documents.

Il convient également de noter que le système Flagship met en œuvre un système unifié apparence sous-systèmes. Le module d'administration générale des éléments de l'interface utilisateur, les fonctions AWP, y compris les menus et les barres d'outils, vous permet de personnaliser l'apparence de manière uniforme.

À l'heure actuelle, le développement de l'informatique nécessite la mise à jour de la plate-forme du système Flagman. Tout d'abord, il est nécessaire de le transférer vers une architecture à trois niveaux et de développer le module de gestion de documents en un système de gestion de processus entièrement fonctionnel. Il est également nécessaire de développer des mécanismes d'intégration d'applications externes, puisque le système n'a que les moyens d'importer et d'exporter des données.

Néanmoins, de nombreux exemples d'implantation et d'exploitation commerciale réussies du système Flagman, la croissance du nombre de ses ventes en 2001-2002 témoignent de l'efficacité économique solutions pour l'automatisation des entreprises de divers domaines d'activité, industries et échelles.

En février 1999, le système Flagman de la société Infosoft, créé sous la direction de l'auteur, a été reconnu comme le meilleur développement russe basé sur la boîte à outils Centura Team Developer par Centura Software Corp. (USA) et la société "Interface" (Russie). En 1999, 2000 et 2001 CIS "Flagman" a été certifié en tant que système d'information à l'échelle de l'entreprise par les experts du jury du concours "Business-Soft", organisé par l'Association des développeurs de logiciels dans le domaine de l'économie (AREP), TSIES "Business Programs-Service », la revue « Comptabilité » et « Journal financier ».

Conception AIS canonique

Développement et conception SIA commence par la création d'un modèle conceptuel pour l'utilisation du système. Tout d'abord, il convient de déterminer la faisabilité de la création d'un système, ses fonctions et tâches spécifiques à automatiser. Une évaluation devrait être faite non seulement des objectifs, mais aussi des possibilités de créer un système. En outre, l'analyse des exigences pour l'AIS, la conception détaillée, la relation des étapes, la programmation et les tests, la minimisation des pertes lors de la transition d'un niveau de présentation des informations à un autre, l'intégration dans le système existant, la mise en œuvre et le support sont effectuées.

Il existe trois classes de méthodologies de conception SIA:
· modélisation conceptuelle du domaine d'étude ;
Identification des besoins et spécification du système d'information à travers son prototypage ;
· architecture système d'outils logiciels pris en charge par les outils de la technologie CASE (CASE - Computer Aided Software Engineering - technologie de création et de maintenance de logiciels pour divers systèmes).

L'étape de création d'un système automatisé - partie du processus de création de la centrale nucléaire, établie par des documents réglementaires et se terminant par la publication de la documentation de la centrale nucléaire, qui doit contenir un modèle de système au niveau de cette étape, la fabrication de composants non série ou la réception de la centrale nucléaire en exploitation .
Chaque étape est individualisée pour des raisons de planification et d'organisation rationnelles du travail et doit nécessairement se terminer par un certain résultat. Le contenu de la documentation à chaque étape est déterminé par la composition et les spécificités du travail.
GOST 34.601-90 définit huit étapes pour créer des systèmes automatisés :

1. Formation des exigences pour AS.
2. Développement du concept AS.
3. Tâche technique.
4. Conception preliminaire.
5. Projet technique.
6. Documents de travail.
7. Mise en service.
8. Prise en charge du courant alternatif.

Il existe trois périodes de création d'un système : avant-projet, conception, mise en service.
Les étapes 1, 2, 3 font référence à la première période, les étapes 4, 5, 6 - à la deuxième période, les étapes 7, 8 - à la troisième.
Dans la période d'avant-projet, une étude de faisabilité (EF) est élaborée et tâche technique(TOR) pour la conception du système. Au cours de cette période, au stade de la formation des exigences pour la centrale nucléaire, trois étapes de travail sont réalisées:

• examen de l'objet du domaine et justification de la nécessité de créer un système;
• formation des besoins des utilisateurs pour le système ;
• rédaction d'un rapport sur les travaux effectués et d'une demande de développement du système.

Au stade de l'élaboration du concept de centrale nucléaire, quatre étapes de travail sont réalisées :

• étude de l'objet;
• effectuer des travaux de recherche;
• sélection d'une variante du concept de système parmi plusieurs développées;
• établissement d'un rapport sur les travaux effectués.

A la 3ème étape, les termes de référence pour la création de l'AS sont élaborés et approuvés.
Termes de référence (TOR) - il s'agit d'une liste des principales exigences opérationnelles, technologiques, économiques et autres que l'objet conçu doit satisfaire à toutes les étapes de son existence Après l'approbation du mandat, la deuxième période de création de la centrale nucléaire commence - la période de système motif.
Concevoir - le processus de choix raisonnable des caractéristiques du système, la formation de modèles logiques-mathématiques et économiques-mathématiques, le développement de la documentation.
Au stade de la création d'un projet de conception, à la 1ère étape, des solutions de conception préliminaires pour le système et ses parties sont développées, à la 2e étape, la documentation de la centrale nucléaire et de ses parties.
A la 5ème étape, lors de la création d'un projet technique, le développement s'effectue en quatre étapes :

• solutions de conception pour le système et ses composants ;
• documentation pour la centrale nucléaire et ses parties ;
• documentation pour la fourniture de produits pour l'acquisition de centrales nucléaires et spécifications techniques pour leur développement;
• tâches n# conception dans les parties adjacentes du projet de l'objet d'automatisation.

La troisième période est la mise en service de la centrale nucléaire. Assurer le développement d'équipements non standard, d'équipements, de matériaux, de produits achetés, d'installation, de mise en service, de mise en œuvre.
A la 7ème étape, le système est mis en service en huit étapes :

• préparation de l'objet d'automatisation pour l'entrée de l'UA ;
• la formation du personnel;
• compléter l'UA avec des logiciels, du matériel, des outils et des produits d'information ;
• travaux de construction et d'installation;
• travaux de mise en service;
• essais préliminaires ;
• opération d'essai;
• essais d'acceptation.

Le contenu des étapes de création de l'AS à différentes étapes
Afin d'améliorer la gestion du processus de conception, chaque étape est détaillée, c'est-à-dire qu'elle est divisée en étapes.
L'étape de création d'un système automatisé est partie de l'étape de création de l'AS, déterminée par la nature de l'œuvre, son résultat ou la spécialisation des interprètes.
Les méthodologies de conception de système modernes doivent fournir une description des objets d'automatisation, une description de la fonctionnalité de l'AIS, une spécification de projet garantissant la réalisation des caractéristiques de système spécifiées, un plan détaillé de création d'un système avec une évaluation du temps de développement et une description de la mise en œuvre d'un système particulier.

Cycle de vie AIS
Au cœur de la création et de l'utilisation SIA réside le concept de cycle de vie (LC).
Le cycle de vie est un modèle pour la création et l'utilisation d'AIS, qui reflète les différents états du système depuis le moment où il apparaît dans un ensemble d'outils donné jusqu'au moment où il est complètement hors d'usage.

Pour les AIS, les principales étapes suivantes de leur cycle de vie sont conditionnellement distinguées :
1. analyse - déterminer ce que le système doit faire ;
2. conception - déterminer comment le système fonctionnera : tout d'abord, la spécification des sous-systèmes, des composants fonctionnels et comment ils interagissent dans le système ;
3. développement - la création de composants fonctionnels et de sous-systèmes individuels, la connexion de sous-systèmes en un seul ensemble;
4. tests - vérification de la conformité fonctionnelle et paramétrique du système avec les indicateurs déterminés au stade de l'analyse ;
5. mise en œuvre - installation et mise en service du système ;
6. support - assurer le processus régulier d'exploitation du système dans l'entreprise du client.

Les étapes de développement, de test et de mise en œuvre de l'AIS sont désignées par un seul terme - mise en œuvre.
À chaque étape du cycle de vie, un certain ensemble de solutions techniques et de documents les reflétant sont générés, tandis que pour chaque étape, les documents et les décisions prises à l'étape précédente sont les premiers.
Les modèles de cycle de vie existants déterminent l'ordre d'exécution des étapes du processus de création d'un système, ainsi que les critères de passage d'une étape à l'autre. Les plus répandus sont les modèles suivants.

Modèle en cascade implique le passage à l'étape suivante après l'achèvement des travaux de l'étape précédente. Ce modèle est utilisé dans la construction de l'AIS, pour lequel au tout début du développement, il est possible de formuler toutes les exigences de manière assez précise et complète. Cela donne aux développeurs la liberté de les implémenter au mieux d'un point de vue technique. Cette catégorie comprend les systèmes de règlement complexes, les systèmes en temps réel et autres. Cependant, cette approche présente un certain nombre d'inconvénients, principalement dus au fait que le processus réel de création d'un système ne s'inscrit jamais complètement dans un schéma rigide. Par exemple, dans le processus de création d'un logiciel, il est nécessaire de revenir aux étapes précédentes et de clarifier ou de réviser les décisions prises précédemment.

modèle en spirale s'appuie sur les premières étapes du cycle de vie : analyse, conception préliminaire et détaillée.
Chaque tour de la spirale correspond à un modèle étape par étape pour créer un fragment ou une version du système, sur lequel les objectifs et les caractéristiques du projet sont spécifiés, sa qualité est déterminée et le travail du prochain tour du système spirale est prévue. Le principal problème est de déterminer le moment du passage à l'étape suivante. Pour le résoudre, il est nécessaire d'introduire des délais pour chacune des étapes du cycle de vie. La transition est effectuée conformément au plan, qui est compilé sur la base des données statistiques obtenues dans les projets précédents, et expérience personnelle développeurs. L'inconvénient de cette approche réside dans les problèmes non résolus et les erreurs commises lors des étapes d'analyse et de conception. Ils peuvent conduire à des problèmes dans les étapes ultérieures et même à l'échec de l'ensemble du projet. Pour cette raison, l'analyse et la conception doivent être réalisées avec un soin particulier.