Cycle de vie des systèmes d'information. Cycle de vie du système d'information

Comme un organisme vivant, chaque produit (bien ou service) a son propre cycle de la vie , qui commence au moment de sa "naissance" (ou, peut-être, au moment de la naissance d'une idée) et se termine par sa "mort", ou son retrait de l'utilisation.

Cycle de la vie SIE – un ensemble d'étapes que traverse un SIE dans son développement à partir du moment où une décision est prise sur sa création jusqu'à la fin de son exploitation.

Cycle de vie économique Système d'Information comprend les étapes suivantes :

1) avant-projet ;

2) conception logique et technique ;

3) conception fonctionnelle (physique);

4) mise en œuvre ;

5) fonctionnement ;

6) retrait.

avant-projet l'étape comprend l'étude et l'analyse du système de gestion de l'entreprise, en identifiant les consommateurs d'informations existants. Le but de cette étape est la formation d'exigences IP qui reflètent correctement et précisément les buts et objectifs de l'organisation cliente. Pour préciser le processus de création d'un SI répondant aux besoins de l'organisation, il faut connaître et articuler clairement quels sont ces besoins. Pour cela, il est nécessaire de déterminer les exigences des clients en matière de SI et de les afficher dans le langage des modèles dans les exigences pour le développement d'un projet SI afin de s'assurer que le futur SI répond aux buts et objectifs de l'organisation.

La tâche de former des exigences pour la propriété intellectuelle est l'une des plus responsables, difficile à formaliser et la plus coûteuse et difficile à corriger en cas d'erreur.

Des outils et des produits logiciels modernes vous permettent de créer rapidement un SI selon des exigences toutes faites. Mais souvent ces systèmes ne satisfont pas les clients, nécessitent de nombreuses améliorations, ce qui entraîne une forte augmentation du coût réel du SI. La principale raison de cette disposition est incorrecte, inexacte ou définition incomplète Exigences en matière de propriété intellectuelle au stade de l'analyse.

A ce stade, les problèmes liés à l'élaboration des termes de référence, d'un plan d'action pour la préparation de la facilité, y compris la formation du personnel et le financement, doivent être résolus. A ce stade, une analyse de faisabilité de la PI est également réalisée, à savoir, elle considère :

faisabilité opérationnelle - est-il possible de créer ce SI, dans quelle mesure son fonctionnement sera-t-il pratique et répondra-t-il aux exigences spécifiées ;

· faisabilité économique – coût, efficacité du point de vue de l'utilisateur ;

Concevoir logique et technique est le développement conformément aux exigences formulées et aux besoins d'information identifiés du système et de l'architecture fonctionnelle de l'EIS.

Au stade de la conception, tout d'abord, des modèles de données sont formés. Les concepteurs reçoivent les résultats de l'analyse en tant qu'informations initiales. La construction de modèles de données logiques et physiques est une partie importante de la conception de bases de données. Le modèle d'information obtenu lors de l'analyse est d'abord converti en un modèle de données logique puis en un modèle de données physique.

Parallèlement à la conception du schéma de la base de données, la conception des processus est réalisée afin d'obtenir les spécifications (descriptions) de l'ensemble des modules du SI. Ces deux processus de conception sont étroitement liés car une partie de la logique métier est généralement implémentée dans la base de données (contraintes, déclencheurs, procédures stockées). L'objectif principal de la conception de processus est de cartographier les fonctions obtenues à l'étape d'analyse dans les modules du système d'information. Lors de la conception des modules, les interfaces du programme sont définies : disposition des menus, apparence des fenêtres, raccourcis clavier et appels associés.

De plus, au stade de la conception, le développement de l'architecture du SI est également réalisé, ce qui inclut le choix de la plate-forme (les plates-formes) et du système d'exploitation (les systèmes d'exploitation). Dans un SI hétérogène, plusieurs ordinateurs peuvent fonctionner sur des plates-formes matérielles différentes et exécuter des systèmes d'exploitation différents.

En plus du choix d'une plate-forme, lors de la conception, des types d'architecture sont déterminés :

architecture « serveur de fichiers » ou « client-serveur » ;

La base de données est centralisée ou distribuée. Si la base de données est distribuée, quels mécanismes seront utilisés pour maintenir la cohérence et la pertinence des données ;

· serveurs, parallèles ou uniques pour les bases de données (afin d'atteindre les performances requises), etc.

La phase de conception se termine par le développement projet technique EST.

Concevoir le travail (physique) comprend la création et la configuration de programmes, le remplissage de bases de données, la création d'instructions de travail pour le personnel. La conception se termine par la création d'un projet de travail.

Un projet de travail est une documentation technique approuvée de la manière prescrite, contenant des données mises à jour et des solutions de conception détaillées à l'échelle du système, des programmes et des instructions pour résoudre les problèmes, ainsi qu'une évaluation mise à jour l'efficacité économique système de contrôle automatisé et une liste mise à jour des mesures pour préparer l'installation à la mise en œuvre.

Au cours de l'expérimentation et de l'industrie la mise en oeuvre un ajustement complet du système et la formation du personnel sont effectués.

La mise en œuvre du système est un processus de transition progressive de l'EIS existant vers un nouveau, prévu par la documentation de projet de travail pour l'ensemble du système. L'introduction de tâches individuelles et de sous-systèmes peut être effectuée parallèlement à l'élaboration d'un projet de travail pour l'ensemble du système.

Les principales étapes de la mise en œuvre du système sont les suivantes :

préparation de l'installation pour la mise en œuvre du système;

livraison de tâches et de sous-systèmes pour une opération d'essai ;

effectuer une opération d'essai ;

livraison des tâches, des sous-systèmes, le système dans son ensemble en exploitation commerciale.

L'opération d'essai du SI consiste à vérifier les algorithmes, les programmes et les liens processus technologique traitement des données en conditions réelles. C'est pour les éléments suivants :

débogage final des programmes et développement du processus technologique de résolution des problèmes;

Vérifier l'état de préparation de la base d'informations ;

· élaborer l'interrelation des tâches du système ;

Acquisition de compétences professionnelles par le personnel de l'entreprise;

Ajustement de l'ensemble du système dans son ensemble et élimination des lacunes identifiées.

Après l'achèvement de l'exploitation pilote du système, un rapport de mise en œuvre est rédigé. Avec les résultats positifs de l'opération d'essai, le système est mis en exploitation commerciale.

Exploitation EIS - son utilisation en conditions réelles. Pendant le fonctionnement, la maintenance, l'analyse du fonctionnement du système, la correction des erreurs et des lacunes, l'enregistrement des exigences et l'élaboration de plans de modernisation et d'expansion du système sont également effectués.

Retrait L'EIS hors service s'appelle la mise hors service complète de l'EIS ou une modernisation importante, ce qui nous permet de parler de la création d'un système d'information fondamentalement nouveau.

Les modèles de cycle de vie existants déterminent l'ordre d'exécution des étapes au cours du développement, ainsi que les critères de passage d'une étape à l'autre. En conséquence, les trois modèles de cycle de vie suivants sont les plus largement utilisés :

1) un modèle en cascade qui implique la transition vers étape suivante après l'achèvement des travaux de l'étape précédente ;

2) modèle étagé avec contrôle intermédiaire, c'est-à-dire modèle de développement itératif avec des boucles de rétroaction entre les étapes. L'avantage de ce modèle est que les ajustements inter-étapes fournissent moins d'intensité de travail par rapport au modèle en cascade, mais la durée de vie de chacune des étapes est prolongée sur toute la période de développement ;

3) le modèle en spirale se concentre sur les premières étapes du cycle de vie : analyse des besoins, conception des spécifications, conception préliminaire et détaillée. A ces étapes, la faisabilité des solutions techniques est vérifiée et justifiée par la réalisation de prototypes. Chaque tour de la spirale correspond à un modèle étape par étape pour créer un fragment ou une version d'un produit logiciel, 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 de la spirale est prévue. Ainsi, les détails du projet sont approfondis et concrétisés de manière cohérente, et en conséquence, une option raisonnable est sélectionnée, qui est mise en œuvre.

A toutes les étapes du cycle de vie du SIE, les spécialistes économiques jouent un rôle important, qui :

formuler des exigences pour le futur système d'information ou un plan pour sa modernisation;

· justifier et calculer l'efficacité économique des solutions individuelles utilisées dans le cadre du SI et du système dans son ensemble ;

· participer directement au processus de création d'un SIE, en aidant à modéliser les processus métiers et leurs processus d'information correspondants, y compris les salariés de l'entreprise pour laquelle un SI est en cours de création, conformément à l'un des principes de création d'un SI.

Participer au débogage du système lors de sa mise en exploitation;

· (experts) utilisent leurs connaissances et leur expérience pour remplir des bases de données et des connaissances ;

· au stade de la mise en œuvre, ils élaborent des instructions et forment le personnel, en appliquant leurs connaissances et leur expérience pratique.

Des études récentes ont montré que les gains de productivité grâce à l'utilisation des technologies de l'information sont rarement atteints. raison principale en ce que les nouvelles technologies de l'information sont souvent des images miroir des méthodes et processus antérieurs. Cette prise de conscience a conduit à

l'émergence d'une nouvelle direction dans le domaine de la gestion - réingénierie processus métier, qui fait référence à l'amélioration ou à l'amélioration d'un processus métier existant grâce à l'utilisation des technologies de l'information avec une refonte fondamentale parallèle et une réorientation radicale des processus métier pour obtenir des améliorations spectaculaires d'indicateurs importants (augmentation de la productivité, amélioration de la qualité, réduction des coûts) .

La notion de cycle de vie est l'une des notions fondamentales de la méthodologie de conception des systèmes d'information. Le cycle de vie d'un système d'information est un processus continu qui commence ! à partir du moment où la décision de créer un système d'information est prise et prend fin au moment de son retrait complet de l'exploitation.

La norme ISO/IEC 12207 définit un cadre de cycle de vie qui contient les processus, les activités et les tâches qui doivent être effectuées lors de la création d'un système d'information. Selon cette norme, la structure du cycle de vie est basée sur trois groupes de processus :

1. les principaux processus du cycle de vie (acquisition, fourniture, développement, exploitation, maintenance) ;

2. processus auxiliaires qui assurent la mise en œuvre des processus principaux (documentation, gestion de la configuration, assurance qualité, vérification, attestation, évaluation, audit, résolution de problèmes) ;

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

Parmi les principaux processus du cycle de vie, le développement, l'exploitation et la maintenance sont de la plus haute importance. Chaque processus est caractérisé par certaines tâches et méthodes pour leur solution, données initiales ; obtenus à l'étape précédente, et les résultats.

1. Développement

Le développement d'un système d'information comprend tous les travaux de développement d'un logiciel d'information et de ses composants conformément aux exigences spécifiées. Le développement de logiciels d'information comprend également :

1. enregistrement de la conception et de la documentation opérationnelle ;

2. préparation du matériel nécessaire au test secret produits logiciels;

3. élaboration du matériel nécessaire à l'organisation de la formation du personnel.

Le développement est l'un des processus les plus importants du cycle de vie d'un système d'information et, en règle générale, comprend la planification stratégique, l'analyse, la conception et la mise en œuvre (programmation).

2. Fonctionnement

Le travail opérationnel peut être divisé en préparatoire et principal. Les préparations comprennent :

1. configuration de la base de données et des postes utilisateurs ;

2. fournir aux utilisateurs une documentation opérationnelle ;

3. formation du personnel.

Les principales activités opérationnelles comprennent ;

1. Opération directe ;

2. localisation des problèmes et élimination de leurs causes ;

3. modifications logicielles ;

4. élaboration de propositions d'amélioration du système ;

5. développement et modernisation du système.

3. Escorte

Prestations de service soutien technique jouent un rôle très important dans la vie de tout système d'information d'entreprise. La disponibilité d'une maintenance qualifiée au stade de l'exploitation du système d'information est une condition préalable à la résolution des tâches qui lui sont assignées. De plus, les erreurs du personnel de maintenance peuvent entraîner des pertes financières évidentes ou cachées comparables au coût du système d'information lui-même.

Modèles de cycle de vie

Le modèle de cycle de vie est compris comme une structure qui détermine la séquence d'exécution et la relation des processus, des activités et des tâches effectuées tout au long du cycle de vie. Le modèle de cycle de vie dépend des spécificités du système d'information et des spécificités des conditions dans lesquelles celui-ci est créé et fonctionne.

A ce jour, les plus utilisés sont les principaux modèles de cycle de vie suivants :

1. modèle de tâche ;

2. modèle en cascade (ou systémique) (70-85) ;

3. modèle en spirale (présent).

Modèle de tâche

Lors du développement d'un système "ascendant" des tâches individuelles au système entier (modèle de tâche), une approche unique du développement est inévitablement perdue, des problèmes surgissent dans l'ancrage informationnel des composants individuels. En règle générale, à mesure que le nombre de tâches augmente, les difficultés augmentent, il est nécessaire de modifier constamment les programmes et les structures de données existants. Le rythme de développement du système ralentit, ce qui ralentit le développement de l'organisation elle-même. Cependant, dans certains cas, cette technologie peut être appropriée :

Extrême urgence (il faut au moins que les tâches soient résolues d'une manière ou d'une autre; alors vous devez tout refaire);

Expérimentation et adaptation du client (les algorithmes ne sont pas clairs, les solutions sont tâtonnées par essais et erreurs).

La conclusion générale est qu'il est impossible de créer un système d'information efficace suffisamment important de cette manière.

Modèle en cascade

Dans les premiers systèmes d'information homogènes, pas très grands, chaque application était un tout unique. Pour développer ce type d'application, une méthode en cascade a été utilisée. Sa principale caractéristique est la division de l'ensemble du développement en étapes, et la transition d'une étape à l'autre ne se produit qu'après l'achèvement complet des travaux sur l'actuelle (Fig. 2). Chaque étape se termine par la libération ensemble complet une documentation suffisante pour que le développement puisse être poursuivi par une autre équipe de développement.

Côtés positifs Les applications de l'approche en cascade sont les suivantes :

à chaque étape, un ensemble complet de documents de projet est formé qui répond aux critères d'exhaustivité et de cohérence ;

les étapes de travail effectuées dans une séquence logique vous permettent de planifier le calendrier d'achèvement de tous les travaux et les coûts correspondants.

Riz. . Plan d'aménagement de la cascade

L'approche en cascade a fait ses preuves dans la construction de systèmes d'information pour lesquels, au tout début du développement, toutes les exigences peuvent être formulées de manière assez précise et complète afin de laisser aux développeurs la liberté de les mettre en œuvre au mieux avec point technique vision. Les systèmes de calcul complexes, les systèmes en temps réel et d'autres tâches similaires entrent dans cette catégorie. Cependant, au cours de l'utilisation de cette approche, un certain nombre de ses lacunes ont été découvertes, principalement en raison du fait que le processus réel de création de systèmes ne s'intègre jamais complètement dans un schéma aussi rigide. Dans le processus de création, il y avait 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 véritable processus de création de logiciel a pris la forme suivante (Fig. 3):

Riz. 3. Le véritable processus de développement logiciel selon le schéma en cascade

Le principal inconvénient de l'approche en cascade est un délai important dans l'obtention des résultats. La coordination des résultats avec les utilisateurs n'est effectuée qu'aux points prévus après la réalisation de chaque étape de travail, les exigences des systèmes d'information sont "figées" sous la forme d'une tâche technique pendant toute la durée de sa création. Ainsi, les utilisateurs ne peuvent soumettre leurs commentaires qu'une fois le travail sur le système entièrement terminé. Si les exigences ne sont pas définies avec précision ou modifiées au cours d'une longue période de développement logiciel, les utilisateurs se retrouvent avec un système qui ne répond pas à leurs besoins. Les modèles (fonctionnels et informationnels) d'un objet automatisé peuvent devenir obsolètes simultanément à leur approbation. L'essence d'une approche systématique du développement du SI réside dans sa décomposition (cloisonnement) 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é conserve une vue globale dans laquelle tous les composants sont interconnectés. Ainsi, ce modèle a le principal avantage d'un développement systématique, et les principaux inconvénients sont lents et coûteux.

modèle en spirale

Pour surmonter ces problèmes, un modèle de cycle de vie en spirale a été proposé (Fig. 4), qui se concentre sur les premières étapes du cycle de vie : analyse et conception. A ces étapes, la faisabilité des solutions techniques est testée par la création de prototypes. Chaque tour de spirale correspond à la création d'une pièce ou d'une version du logiciel, sur laquelle les objectifs et les caractéristiques du projet sont spécifiés, sa qualité est déterminée et le travail du prochain tour de spirale est planifié. Ainsi, les détails du projet sont approfondis et concrétisés de manière cohérente, et en conséquence, une option raisonnable est sélectionnée, qui est mise en œuvre.

Le développement par itérations reflète le cycle en spirale objectivement existant de la création du système. L'achèvement incomplet des travaux à chaque étape vous permet de passer à l'étape suivante sans attendre l'achèvement complet des travaux sur l'actuelle. Avec le développement itératif, le travail manquant peut être complété à l'itération suivante. La tâche principale est de montrer aux utilisateurs du système un produit réalisable dès que possible, activant ainsi le processus de clarification et de complément des exigences.

Le principal problème du cycle en spirale est de déterminer le moment de la transition vers 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 se déroule comme prévu, même si tous les travaux prévus ne sont pas terminés. Le plan est établi sur la base de données statistiques obtenues lors de projets antérieurs et de l'expérience personnelle des développeurs.

Figure 4. Modèle en spirale du cycle de vie du SI

Une des approches possibles du développement logiciel dans le cadre du modèle de cycle de vie en spirale est Ces derniers temps méthodologie répandue pour le développement rapide d'applications RAD (Rapid Application Development). Ce terme est généralement compris comme un processus de développement logiciel contenant 3 éléments :

une petite équipe de programmeurs (de 2 à 10 personnes) ;

court mais bien ficelé calendrier de production(de 2 à 6 mois);

un cycle itératif dans lequel les développeurs, au fur et à mesure que l'application prend forme, demandent et implémentent dans le produit les exigences reçues par l'interaction avec le client.

Le cycle de vie du logiciel selon la méthodologie RAD se compose de quatre phases :

1. phase de définition et d'analyse des besoins ;

2. phase de conception ;

3. phase de mise en œuvre ;

4. phase de mise en œuvre.

Cours 6. Classification des systèmes d'information

Système d'Information- un ensemble interconnecté de moyens, de méthodes et de personnels utilisés pour stocker, traiter et diffuser des informations dans l'intérêt de la réalisation de l'objectif

Classement à l'échelle

Par échelle, les systèmes d'information sont répartis dans les groupes suivants :

1. célibataire ;

2. groupe ;

3. entreprise.

Systèmes d'information uniques généralement mis en œuvre sur un stand-alone ordinateur personnel(réseau non utilisé). Un tel système peut contenir plusieurs applications simples reliées par un fonds d'information commun, et est conçu pour le fonctionnement d'un utilisateur ou d'un groupe d'utilisateurs qui partagent un lieu de travail dans le temps. De telles applications peuvent être créées à l'aide de systèmes de gestion de base de données (SGBD) dits de bureau ou locaux. Parmi les SGBD locaux, les plus connus sont Clarion, Clipper, FoxPro, Paradox, dBase et Microsoft Access.

Systèmes d'information du groupe sont centrés sur l'utilisation collective de l'information par les membres du groupe de travail et sont le plus souvent construits sur la base d'un réseau local. Ces applications sont développées à l'aide de serveurs de bases de données (également appelés serveurs SQL) pour les groupes de travail. Il existe un assez grand nombre de serveurs SQL différents, à la fois commerciaux et librement distribués. Parmi eux, les serveurs de base de données les plus connus sont Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Systèmes d'information d'entreprise sont une évolution des systèmes pour les groupes de travail, ils sont axés sur les grandes entreprises et peuvent prendre en charge des nœuds ou des réseaux géographiquement dispersés. Fondamentalement, ils ont une structure hiérarchique de plusieurs niveaux. De tels systèmes se caractérisent par une architecture client-serveur avec spécialisation des serveurs ou une architecture multi-niveaux. Lors du développement de tels systèmes, les mêmes serveurs de base de données peuvent être utilisés que lors du développement de systèmes d'information de groupe. Cependant, dans les grands systèmes d'information, les serveurs les plus utilisés sont Oracle, DB2 et Microsoft SQL Server.

Pour les systèmes de groupe et d'entreprise, les exigences en matière de fiabilité de fonctionnement et de sécurité des données sont considérablement accrues. Ces propriétés sont fournies en maintenant l'intégrité des données, des liens et des transactions dans les serveurs de base de données.

Classement par périmètre

Selon la portée des systèmes d'information sont généralement divisés en quatre groupes:

1. systèmes de traitement des transactions ;

2. systèmes de prise de décision ;

3. systèmes d'information et de référence ;

4. systèmes d'information de bureau.

Systèmes de traitement des transactions, à leur tour, selon l'efficacité du traitement des données, sont divisés en systèmes d'information par lots et systèmes d'information opérationnels. Dans les systèmes d'information de gestion organisationnelle, le mode de traitement opérationnel des transactions prévaut, pour refléter à jour l'état du domaine à tout moment, et le traitement par lots occupe une part très limitée.

Systèmes d'aide à la décision - DSS (Decision Support Systeq) - sont un autre type de systèmes d'information dans lesquels, à l'aide de requêtes assez complexes, les données sont sélectionnées et analysées dans différentes sections: indicateurs temporels, géographiques et autres.

Classe étendue systèmes d'information et de référenceà partir de documents hypertextes et multimédia. De tels systèmes d'information ont connu le plus grand développement sur Internet.

Classer systèmes d'information de bureau vise la dématérialisation des documents papier, la bureautique et la gestion documentaire.

Classement par voie d'organisation

Selon le mode d'organisation, les systèmes d'information du groupe et de l'entreprise sont répartis dans les classes suivantes:

1. systèmes basés sur une architecture de serveur de fichiers ;

2. systèmes basés sur une architecture client-serveur ;

3. des systèmes basés sur une architecture multi-niveaux ;

4. systèmes basés sur les technologies Internet/Intranet.

Dans tout système d'information, il est possible d'identifier les composants fonctionnels nécessaires qui permettent de comprendre les limites des différentes architectures du système d'information.

Architecture du serveur de fichiers extrait uniquement les données des fichiers afin que les utilisateurs et applications supplémentaires n'ajoutent qu'une charge mineure au processeur. Chaque nouveau client ajoute de la puissance de traitement au réseau.

Architecture client-serveur est conçu pour résoudre les problèmes des applications de serveur de fichiers en séparant les composants de l'application et en les plaçant là où ils fonctionneront le plus efficacement. Une caractéristique de l'architecture client-serveur est l'utilisation de serveurs de base de données dédiés qui comprennent les requêtes dans le langage SQL (Structured Query Language) et effectuent des recherches, un tri et une agrégation d'informations.

Actuellement, l'architecture client-serveur est reconnue et largement utilisée comme moyen d'organiser les applications pour les groupes de travail et les systèmes d'information au niveau de l'entreprise. Cette organisation du travail augmente l'efficacité d'exécution des applications en utilisant les capacités du serveur de base de données, en déchargeant le réseau et en assurant le contrôle de l'intégrité des données.

Architecture en couches est devenu le développement de l'architecture client-serveur et dans sa forme classique se compose de trois niveaux :

1. La couche inférieure correspond aux applications clientes qui disposent d'une interface de programmation pour appeler l'application de la couche intermédiaire ;

2. niveau moyen est un serveur d'applications ;

3. Le niveau supérieur est un serveur de base de données spécialisé distant.

L'architecture à trois niveaux équilibre davantage la charge entre les différents hôtes et réseaux, favorise la spécialisation des outils de développement d'applications et élimine les lacunes du modèle client-serveur à deux niveaux.

En développement technologies Internet/intranet jusqu'à présent, l'accent est mis principalement sur le développement d'outils logiciels. Dans le même temps, il y a un manque d'outils développés pour développer des applications qui fonctionnent avec des bases de données. Une solution de compromis pour créer des systèmes d'information pratiques et faciles à utiliser et à entretenir qui fonctionnent efficacement avec des bases de données était la combinaison de la technologie Internet / Intranet avec une architecture à plusieurs niveaux. Dans ce cas, la structure de l'application d'information prend la forme suivante : navigateur - serveur d'application - serveur de base de données - serveur de pages dynamiques - serveur web.

Selon la nature des informations stockées, les bases de données sont divisées en factuel et documentaires. Si l'on fait une analogie avec les exemples de référentiels d'informations décrits ci-dessus, alors les bases de données factographiques sont des classeurs, et les bases de données documentaires sont des archives. Magasin de bases de données factuelles informations courtes dans un format strictement défini. Les bases de données documentaires contiennent toutes sortes de documents. Et ce peut être non seulement document texte mais aussi graphisme, vidéo et son (multimédia).

Le système de contrôle automatisé (ACS) est un ensemble de matériel et de logiciels, ainsi que Structures organisationnelles(personnes individuelles ou équipe), assurant la gestion d'un objet (complexe) dans un environnement industriel, scientifique ou social.

Allouer les systèmes d'information de gestion de l'éducation (par exemple, les programmes du personnel, du candidat, de l'étudiant, de la bibliothèque). Systèmes automatisés pour recherche scientifique(ASNI), qui sont des systèmes logiciels et matériels qui traitent les données de divers types de montages expérimentaux et d'instruments de mesure et, sur la base de leur analyse, facilitent la détection de nouveaux effets et modèles.Systèmes de conception assistée par ordinateur et systèmes d'information géographique.

Un système d'intelligence artificielle construit sur la base de connaissances spéciales de haute qualité sur un certain domaine (obtenues auprès d'experts - spécialistes dans ce domaine) est appelé système expert. Les systèmes experts - l'un des rares types de systèmes d'intelligence artificielle - sont largement utilisés et trouvés utilisation pratique. Il existe des systèmes experts pour les affaires militaires, la géologie, l'ingénierie, l'informatique, la technologie spatiale, les mathématiques, la médecine, la météorologie, l'industrie, l'agriculture, la gestion, la physique, la chimie, l'électronique, le droit, etc. Et seul le fait que les systèmes experts restent des programmes très complexes, coûteux et, surtout, hautement spécialisés, entrave leur diffusion encore plus large.

Les systèmes experts (ES) sont logiciels d'ordinateur, créé pour effectuer ces types d'activités qui sont à la portée d'un expert humain. Ils fonctionnent d'une manière qui imite le comportement d'un expert humain et diffère considérablement des algorithmes précis et bien raisonnés et ne ressemble pas aux procédures mathématiques de la plupart des développements traditionnels.

Du cursus de travail :

Thème 2. Normes et lignes directrices normatives pour l'ingénierie système et logicielle.

ISO/CEI 15288 "Ingénierie des systèmes - Processus du cycle de vie des systèmes".

GOST 34 : Un ensemble de normes pour les systèmes automatisés.

Idées clés de l'ingénierie système : approche système, cycle de vie du système, ingénierie des exigences, conception architecturale, approche processus, approche de conception.

2.1. ISO 15288 "Ingénierie des systèmes - Processus du cycle de vie des systèmes".

2.2. Cycle de vie du système.

2.3. Vues du cycle de vie du système.

2.4. Cycle de vie du système d'information

2.5. Modèles de cycle de vie

2.6. Choisir un modèle de cycle de vie

2.1. ISO 15288 "Ingénierie des systèmes - processus du cycle de vie des systèmes".

L'ingénierie des systèmes est appliquée pour résoudre les problèmes associés à la complexité croissante des systèmes créés par l'homme. La norme ISO 15288, qui décrit les méthodes d'ingénierie des systèmes, prescrit d'avoir une description du cycle de vie du système et de ses pratiques. Une telle description est nécessaire pour le bon déroulement du système tout au long du cycle de vie. Mais la norme n'indique pas les méthodes par lesquelles une telle description doit être créée.

Objectifs de la norme :

Permettre aux organisations (entrepreneurs internes et externes) de s'entendre sur la combinaison d'idées, de processus de conception, de construction, d'exploitation et de démantèlement d'une grande variété de systèmes artificiels - des cure-dents aux centrales nucléaires, des systèmes de normalisation aux entreprises

Mettre en œuvre un certain nombre d'idées clés de l'ingénierie des systèmes dans la pratique de l'organisation :

• approche systémique

  cycle de la vie

  ingénierie des exigences

  conception architecturale

  approche processus

  approche projet

  culture de la contractualisation

Esttoriyacréation

Développement conjoint de l'ISO et de la CEI, participation active de l'INCOSE

Début des travaux en 1996, versions en 2002, 2005 (GOST R ISO / IEC 15288-2005), 2008

Conçu pour harmoniser le soi-disant «marais de normes» de l'ingénierie des systèmes (nombreuses normes adoptées par divers départements militaires, États, organismes de normalisation de l'industrie)

Des experts de divers domaines ont participé à l'élaboration de la norme : ingénierie des systèmes, programmation, gestion de la qualité, ressources humaines, sécurité, etc. L'expérience pratique de la création de systèmes dans des organisations gouvernementales, commerciales, militaires et universitaires a été prise en compte. La norme est applicable à une large classe de systèmes, mais son objectif principal est de soutenir la création de systèmes informatisés.

2.2. Cycle de vie du système

Abréviation russe : J C

Abréviation anglaise : CL (La viecycle)

Russe: "cycle de la vie". Le cycle de vie anglais de la technologie signifiait et se traduisait par "durée de vie", et parfois même "durée de vie jusqu'à la première révision majeure". "Life Cycle" est une traduction relativement nouvelle. Parfois, «cycle» est traduit par «période», mais une telle traduction ne s'est pas établie (bien qu'elle soit plus précise dans ce cas: la «période de vie» du système). Le mot "cycle" ne doit pas prêter à confusion - il n'y a rien de cyclique dans le cycle de vie. Le mot "cycle" a le sens de "typique", ce qui signifie que la même chose se produit avec d'autres systèmes.

Formellement : le cycle de vie est un changement dans les états du système (évolution du système) dans la période allant de la conception à la fin de son existence.

Le système et le cycle de vie sont des frères jumeaux. Nous disons système - nous entendons le cycle de vie, nous disons cycle de vie - nous entendons le système.

Définitions.

Définition de l'ISO/IEC 15288:2008 (Définition : cycle de vie -- évolution d'un système, d'un produit, d'un service, d'un projet ou d'une autre entité créée par l'homme, de sa conception à son retrait (ISO 15288, 4.11) :

cycle de la vie (Cycle de vie) est l'évolution d'un système, d'un produit, d'un service, d'un projet ou d'un autre objet créé par l'homme, de sa conception à son abandon.

Définition de la norme ISO 15704 (Systèmes d'automatisation industrielle - Exigences pour les architectures et méthodologies de référence d'entreprise

cycle de la vie (LC) est un ensemble fini de phases et d'étapes principales que le système traverse tout au long de l'histoire de l'existence.

Chaque système, quel que soit son type et son échelle, passe par tout son cycle de vie selon une description. La progression du système à travers les parties de cette description est le cycle de vie du système. La description du cycle de vie est donc - il s'agit d'une segmentation conceptuelle par étapes faciliter la planification, le déploiement, l'exploitation et le support du système cible.

Les étapes (tableau 2.1) représentent les plus grandes périodes du cycle de vie associé à un système et correspondent aux états de la description du système ou de la mise en œuvre du système en tant qu'ensemble de produits ou de services. Les étapes décrivent les principales étapes de progression et de réussite du système au cours du cycle de vie. Ces segments permettent au système de progresser de manière ordonnée grâce à des révisions établies de l'allocation des ressources, ce qui réduit les risques et garantit des progrès satisfaisants. La principale raison d'utiliser les descriptions du cycle de vie est la nécessité de prendre des décisions sur certains critères avant de faire passer le système à l'étape suivante.

Tableau 2.1

Étapes de développement du système (ISO/IEC 15288)
№ n/n	Organiser	La description
	Formation conceptuelle	Analyse des besoins, sélection du concept et du design
	Développement	Conception du système
	Mise en œuvre	Fabrication du système
	Exploitation	Mise en service et utilisation du système
	Soutien	Assurer le fonctionnement du système
	Déclassement	Cessation d'utilisation, démontage, archivage du système

cycle (CL).

ZHIS est la période de création et d'utilisation du SI, à partir du moment où le besoin de SI se fait sentir et se terminant au moment où il est complètement hors service.

Le cycle de vie est un modèle de création et d'utilisation d'un logiciel, reflétant ses différents états, à partir du moment où le besoin de ce produit logiciel se fait sentir et se terminant au moment où il est complètement hors d'usage pour tous les utilisateurs.

Traditionnellement, on distingue les principales étapes suivantes du cycle de vie d'un logiciel :

• analyse des besoins;
• motif;
• codage (programmation);
• test et débogage ;
• opération et maintenance.

Les étapes du cycle de vie d'un système d'information

1. Enquête avant projet
   • 1.1. Collection de matériaux pour la conception; dans le même temps, la formulation des besoins, l'étude de l'objet d'automatisation sont pointés du doigt, des conclusions préliminaires de la version de pré-conception du SI sont données.
   • 1.2. Analyse des matériaux et développement de la documentation ; une étude de faisabilité avec une mission technique pour Conception de CI.
2. Concevoir
   • 2.1. Conception preliminaire:
     • sélection de solutions de conception sur des aspects de développement du SI ;
     • description des composants réels du SI ;
     • exécution et approbation du projet technique (TP).
   • 2.2. Conception détaillée:
     • sélection ou développement de méthodes mathématiques ou d'algorithmes de programme;
     • ajustement des structures de bases de données ;
     • création de documentation pour la livraison et l'installation de produits logiciels;
     • sélection d'un complexe de moyens techniques avec documentation pour son installation.
   • 2.3. Développement d'un projet de techno-travail de la propriété intellectuelle (TRP).
   • 2.4. Elaboration d'une méthodologie de mise en œuvre des fonctions de gestion à l'aide du SI et d'une description des régulations des actions de l'appareil de gestion.
3. Développement SI
   • réception et installation du matériel et des logiciels ;
   • test et mise au point du progiciel ;
   • développement d'instructions pour le fonctionnement de logiciels et de matériel informatique.
4. Mise en service du SI
   • apport de moyens techniques ;
   • saisie de logiciels ;
   • formation et certification du personnel;
   • opération d'essai;
   • livraison et signature des actes de réception et de livraison des travaux.
5. Fonctionnement IP
   • fonctionnement quotidien;
   • soutien général de l'ensemble du projet.

Le cycle de vie est formé selon le principe conception descendante et, en règle générale, est de nature itérative : les étapes mises en œuvre, en commençant par les plus anciennes, sont répétées cycliquement en fonction des modifications des exigences et des conditions externes, de l'introduction de restrictions, etc. A chaque étape du cycle de vie, un certain ensemble de documents et de solutions techniques est généré ; en même temps, pour chaque étape, les documents et décisions obtenus à l'étape précédente sont les premiers. Chaque étape se termine par la vérification des documents et solutions générés afin de vérifier leur conformité avec ceux d'origine.

Le principal document réglementaire réglementant le cycle de vie des logiciels est la norme internationale ISO/CEI 12207 (ISO - Organisation internationale de normalisation - Organisation internationale de normalisation, CEI - Commission électrotechnique internationale - Commission électrotechnique internationale). Il définit une structure de cycle de vie qui contient les processus, les activités et les tâches qui doivent être réalisées lors du développement logiciel.

La structure du cycle de vie du logiciel selon la norme ISO/IEC 12207 repose sur trois groupes de processus :

• les principaux processus du cycle de vie du logiciel (acquisition, fourniture, développement, exploitation, maintenance) ;
• processus auxiliaires qui assurent la mise en œuvre des processus principaux (documentation, gestion de la configuration, assurance qualité, vérification, certification, évaluation, audit, résolution de problèmes) ;
• processus organisationnels (gestion de projet, création d'infrastructure de projet, définition, évaluation et amélioration du cycle de vie lui-même, formation).

Le développement comprend tous les travaux de création de logiciels et de ses composants conformément aux exigences spécifiées. Cela comprend l'exécution de la documentation de conception et d'exploitation, la préparation des matériaux nécessaires pour tester l'opérabilité et les qualité des produits logiciels, matériels nécessaires à l'organisation de la formation du personnel, etc. Le développement de logiciels comprend généralement l'analyse, la conception et la mise en œuvre (programmation).

L'exploitation comprend les travaux de mise en service des composants logiciels. Ce processus comprend la configuration de la base de données et des postes de travail des utilisateurs, la fourniture de la documentation opérationnelle, la formation du personnel, etc., et l'exploitation directe, y compris la localisation des problèmes et l'élimination des causes de leur apparition, la modification des logiciels dans le cadre des réglementations établies, la préparation de propositions d'amélioration, de développement et modernisation du système.

La gestion de projet est liée aux problématiques de planification et d'organisation du travail, de constitution d'équipes de développeurs et de suivi des délais et de la qualité des travaux réalisés. L'accompagnement technique et organisationnel du projet comprend le choix des méthodes et outils de mise en œuvre du projet, la définition des méthodes de description des états intermédiaires de développement, le développement des méthodes et outils de test logiciel, la formation du personnel, etc. L'assurance qualité du projet est liée aux problèmes de vérification, de vérification et de test des logiciels.

La vérification est le processus visant à déterminer si l'état actuel de développement atteint à un stade donné répond aux exigences de ce stade. La validation permet d'évaluer la conformité des paramètres de développement avec les exigences d'origine. La vérification chevauche les tests, qui visent à identifier les différences entre les résultats réels et attendus et à évaluer si les fonctionnalités du logiciel répondent aux exigences d'origine. En cours de réalisation du projet place importante les questions d'identification, de description et de contrôle de la configuration des composants individuels et de l'ensemble du système dans son ensemble sont occupées.

La gestion de la configuration est l'un des processus auxiliaires qui prennent en charge les principaux processus du cycle de vie du logiciel, principalement les processus de développement et de maintenance du logiciel. Lors de la création de projets SI complexes constitués de nombreux composants, dont chacun peut avoir des variétés ou des versions, se pose le problème de prendre en compte leurs relations et leurs fonctions, de créer une structure unifiée et d'assurer le développement de l'ensemble du système. La gestion de configuration permet d'organiser, de prendre en compte et de contrôler systématiquement les évolutions du logiciel à toutes les étapes du cycle de vie. Principes généraux et les recommandations pour la comptabilisation de la configuration, la planification et la gestion des configurations logicielles sont reflétées dans le projet de norme ISO 12207-2.

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. Les résultats de l'analyse, en particulier, sont des modèles fonctionnels, des modèles d'information et leurs diagrammes correspondants. Le cycle de vie du logiciel est de nature itérative : les résultats de l'étape suivante entraînent souvent des changements dans les décisions de conception prises aux étapes précédentes.

CONFÉRENCE 10

CYCLE DE VIE DU SYSTÈME

Modèles de cycle de vie et ses principales étapes

Lors de la description du cycle de vie d'un système, les concepts suivants sont utilisés :

processus - une chaîne de travaux exécutés séquentiellement;

étapes - périodes de temps successives pendant lesquelles le travail est effectué . Au cours de l'étape, des travaux liés à différents processus peuvent être effectués. La base de la création et de l'utilisation d'un système de gestion d'entreprise automatisé (AMS) est le concept de son cycle de vie (LC). LC est un modèle pour la création et l'utilisation de systèmes de contrôle automatisés, reflétant ses différents états, à partir du moment où le besoin de ce produit se fait sentir et se terminant au moment où il est complètement hors d'usage pour tous les utilisateurs sans exception.

Traditionnellement, on distingue les principales étapes suivantes du cycle de vie des systèmes de contrôle automatisé :

analyse des besoins;

motif;

programmation/mise en œuvre ;

test et débogage ;

opération et maintenance.

Le cycle de vie est formé selon le principe de la conception descendante et, en règle générale, est de nature itérative : les étapes mises en œuvre, en commençant par les plus anciennes, sont répétées cycliquement en fonction des modifications des exigences et des conditions externes, la introduction de contraintes, etc. A chaque étape du cycle de vie, un certain ensemble de documents et de solutions techniques, tandis que pour chaque étape les documents et solutions obtenus à l'étape précédente sont les premiers. Chaque étape se termine par la vérification des documents et solutions générés afin de vérifier leur conformité avec ceux d'origine.

Les modèles de cycle de vie existants déterminent l'ordre d'exécution des étapes au cours du développement, ainsi que les critères de passage d'une étape à l'autre. Conformément à cela, les trois modèles de cycle de vie suivants sont les plus largement utilisés :

1. Modèle en cascade(dans les années 70-80) - implique le passage à l'étape suivante après l'achèvement des travaux de l'étape précédente et se caractérise par une séparation claire des données et des processus pour leur traitement.

2. Modèle étagé avec contrôle intermédiaire(dans les années 80-85) - un modèle de développement itératif avec des boucles de rétroaction entre les étapes. L'avantage de ce modèle est que les ajustements entre les étapes demandent moins de main-d'œuvre que le modèle en cascade ; d'autre part, la durée de vie de chacune des étapes est prolongée sur toute la période de développement.

3. Modèle en spirale(dans les années 86-90) - se concentre sur les premières étapes du cycle de vie : analyse des besoins, conception des spécifications, conception préliminaire et détaillée. A ces étapes, la faisabilité des solutions techniques est vérifiée et justifiée par la réalisation de prototypes. 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 spirale est prévue. Ainsi, les détails du projet sont approfondis et concrétisés de manière cohérente, et en conséquence, une option raisonnable est sélectionnée, qui est mise en œuvre.

Les experts notent les avantages suivants du modèle en spirale:

accumulation et réutilisation d'outils logiciels, de modèles et de prototypes ;

orientation au développement et à la modification du système dans le processus de sa conception;

analyse des risques et des coûts dans le processus de conception

. Notez que la principale caractéristique de l'industrie APCS est la concentration de la complexité aux étapes initiales du cycle de vie (analyse, conception) avec une complexité et une intensité de travail relativement faibles aux étapes suivantes. De plus, les problèmes non résolus et les erreurs commises lors des phases d'analyse et de conception donnent lieu à des problèmes difficiles, souvent insolubles dans les étapes ultérieures et, en fin de compte, peuvent priver le succès.

Analyse des besoins

L'analyse des exigences est la première phase du développement d'un système de contrôle automatisé, dans laquelle les exigences du client sont spécifiées, formalisées et documentées. En effet, à ce stade, une réponse est apportée à la question : « Que doit faire le futur système ? ». C'est là que réside la clé de la réussite de l'ensemble du projet. Dans la pratique de la création grands systèmes il existe de nombreux exemples de mise en œuvre de projet infructueuse précisément en raison de l'incomplétude et du flou de la définition Configuration requise.

La liste des exigences pour le système de contrôle automatisé devrait inclure :

L'ensemble des conditions dans lesquelles il est censé faire fonctionner le futur système (ressources matérielles et logicielles fournies au système ; conditions externes de son fonctionnement ; composition des personnes et des travaux qui lui sont liés) ;

Description des fonctions exécutées par le système ;

Limitations dans le processus de développement (délais directifs pour l'achèvement des différentes étapes, ressources disponibles, procédures organisationnelles et mesures pour assurer la protection des informations).

Le but de l'analyse est de transformer les connaissances communes et peu claires sur les exigences du futur système en définitions précises (si possible). Le résultat de l'étape doit être un modèle d'exigences système (en d'autres termes, un projet système) , définissant :

Architecture du système, ses fonctions, conditions externes, répartition des fonctions entre les parties matérielles et logicielles (FC) ;

Interfaces et répartition des fonctions entre une personne et un système ;

Conditions requises pour les composants logiciels et d'information de l'onduleur , ressources matérielles nécessaires, exigences de la base de données, caractéristiques physiques des composants du lecteur, leurs interfaces. Le modèle d'exigences doit inclure :

Un modèle fonctionnel complet d'exigences pour le futur système avec une profondeur d'étude au niveau de chaque opération de chaque fonctionnaire ;

Spécifications des opérations de niveau inférieur ;

Un ensemble de rapports et de documents sur un modèle fonctionnel, comprenant une description de l'objet de modélisation, une liste de sous-systèmes, des exigences pour les méthodes et moyens de communication pour l'échange d'informations entre composants, des exigences pour les caractéristiques des interconnexions du système avec des systèmes adjacents, des exigences pour les fonctions système ;

Modèle d'information conceptuel des exigences ;

Un ensemble de rapports et de documents sur le modèle d'information ;

Architecture du système en référence au modèle d'information conceptuel ;

Suggestions de structure organisationnelle pour soutenir le système.

Ainsi, le modèle d'exigences contient des modèles fonctionnels, informationnels et, éventuellement, événementiels (si le système cible est un système temps réel), offrant de nombreux avantages par rapport au modèle traditionnel :

1. Le développement traditionnel se caractérise par la mise en œuvre des étapes initiales de manière artisanale non formalisée. En conséquence, les clients et les utilisateurs peuvent voir le système pour la première fois après qu'il a déjà été largement mis en œuvre. Naturellement, ce système sera différent de ce qu'ils s'attendaient à voir. Par conséquent, plusieurs autres itérations de son développement ou de sa modification suivront, ce qui nécessite des coûts supplémentaires (et importants) en argent et en temps. La clé pour résoudre ce problème est le modèle des exigences, qui permet :

Décrire, « voir » et corriger le futur système avant sa mise en œuvre physique ;

Réduire le coût de développement et de mise en œuvre du système ;

Évaluer le développement en termes de temps et de résultats ;

Atteindre une compréhension mutuelle entre tous les participants au travail (clients, utilisateurs, développeurs, programmeurs, etc.) ;

Améliorer la qualité du système développé, à savoir effectuer sa décomposition fonctionnelle et concevoir la structure optimale de la base de données intégrée.

2. Le modèle d'exigences est complètement indépendant et séparable de développeurs spécifiques, ne nécessite pas de maintenance par ses créateurs et peut être facilement transféré à d'autres. De plus, si pour une raison quelconque l'entreprise n'est pas prête à mettre en œuvre le système basé sur le modèle d'exigences, il peut être mis «sur l'étagère» jusqu'à ce que le besoin se fasse sentir.

3. Le modèle d'exigences peut être utilisé pour le développement indépendant ou l'ajustement d'outils logiciels déjà mis en œuvre sur sa base par les programmeurs du département d'automatisation de l'entreprise.

4. Le modèle d'exigences peut être utilisé pour la formation automatisée et rapide de nouveaux employés dans un domaine spécifique de l'entreprise, car sa technologie est contenue dans le modèle.

L'étape d'analyse des exigences est la plus importante parmi toutes les étapes du cycle de vie. Il a un impact significatif sur toutes les étapes ultérieures, étant en même temps le processus le moins étudié et le moins compris. A ce stade, d'une part, il est nécessaire de comprendre ce qui est censé être fait, et d'autre part, de le documenter, car si les exigences ne sont pas fixées et mises à la disposition des participants au projet, alors elles ne semblent pas exister. Dans le même temps, le langage dans lequel les exigences sont formulées doit être assez simple et compréhensible pour le client.

D'autre part, l'étape considérée du cycle de vie est la partie la plus difficile du développement. Les problèmes suivants rencontrés par un analyste de systèmes sont interdépendants (et c'est l'une des principales raisons de leur difficulté à résoudre):

L'analyste ne dispose pas toujours d'informations complètes pour évaluer les exigences du système du point de vue du client ;

Le client, à son tour, ne dispose pas d'informations suffisantes sur le problème de traitement des données pour juger de ce qui est faisable et de ce qui ne l'est pas ;

L'analyste est confronté à une quantité excessive de détails à la fois sur le domaine et sur le nouveau système ;

La spécification de système traditionnelle (textuelle) est souvent incompréhensible pour le client en raison du volume de termes techniques ;

Si une telle spécification est comprise par le client, elle ne sera pas suffisante pour que les concepteurs et les programmeurs créent ou adaptent le système.

Bien sûr, l'utilisation de méthodes d'analyse bien connues supprime les problèmes d'analyse individuels, mais une solution acceptable à l'ensemble de ces problèmes ne peut être trouvée qu'en appliquant des méthodes modernes d'ingénierie système et logicielle, parmi lesquelles la place clé est occupée par le méthodologies d'analyse structurelle et orientée objet.

Méthodes d'analyse structurelle

L'analyse structurelle est généralement appelée une méthode d'étude d'un système, qui commence par Aperçu puis il est détaillé, acquérant une structure hiérarchique avec un nombre croissant de niveaux . Ces méthodes se caractérisent par :

Décomposition en niveaux d'abstraction avec une limite du nombre d'éléments à chacun des niveaux (généralement de 3 à 7, tandis que la limite supérieure correspond aux capacités du cerveau humain à percevoir un certain nombre d'objets interconnectés, et la limite inférieure est choisi pour des raisons de bon sens);

Contexte limité, comprenant uniquement les détails essentiels à chaque niveau ;

Utilisation de règles d'enregistrement formelles strictes ;

Approche cohérente du résultat final.

Les méthodes d'analyse structurale permettent de s'affranchir de la complexité des grands systèmes en les divisant en parties (« boîtes noires ») et en hiérarchisant ces boîtes noires. . L'avantage d'utiliser des boîtes noires est que l'utilisateur n'a pas besoin de savoir comment elles fonctionnent, seulement leurs entrées et sorties, et leur objectif (c'est-à-dire la fonction qu'elles remplissent). Dans le monde qui nous entoure, on trouve des boîtes noires dans en grand nombre: un magnétophone et un téléviseur au niveau du foyer, une entreprise du point de vue du client, etc. Illustrons les avantages des systèmes qui en sont constitués, en prenant l'exemple d'un centre de musique.

La conception du système de boîte noire est grandement simplifiée. Il est beaucoup plus facile de concevoir un magnétophone ou une platine si vous n'avez pas à vous soucier de la construction d'une unité d'amplification intégrée.

Le test de tels systèmes est facilité. Si vous entendez un mauvais son provenant de l'un des haut-parleurs, vous pouvez échanger les haut-parleurs. Si le dysfonctionnement s'est déplacé avec la colonne, c'est elle qui doit être réparée; sinon, le problème vient de l'amplificateur, du magnétophone ou de l'endroit où ils sont connectés.

Il est possible de reconfigurer facilement le système de boîte noire. Si le haut-parleur est défectueux, vous pouvez l'apporter à un atelier de réparation et continuer à écouter les enregistrements en mode mono.

Facilite l'accessibilité pour la compréhension et la maîtrise. Il est possible de devenir un spécialiste du magnétophone sans connaissance approfondie des locuteurs.

La facilité de modification est améliorée. Vous pouvez obtenir de meilleurs haut-parleurs et un amplificateur plus puissant, mais cela ne signifie pas que vous avez besoin d'une platine plus grande.

Ainsi, la première étape de la simplification d'un système complexe consiste à le diviser en boîtes noires (le principe du « diviser pour régner » est le principe de résoudre des problèmes difficiles en les décomposant en plusieurs tâches indépendantes faciles à comprendre et à résoudre), tandis que de telles une division doit satisfaire aux critères suivants :

Chaque boîte noire doit implémenter une seule fonction du système ;

La fonction de chaque boîte noire doit être facilement comprise, quelle que soit la complexité de sa mise en œuvre (par exemple, un système de contrôle de fusée peut avoir une boîte noire pour calculer son lieu d'atterrissage : malgré la complexité de l'algorithme, la fonction de la boîte noire est évident - calcul du point d'atterrissage);

La communication entre les boîtes noires ne doit être saisie que s'il existe une connexion entre les fonctions correspondantes du système (par exemple, en comptabilité, une boîte noire est nécessaire pour calculer le salaire total d'un employé et l'autre est nécessaire pour calculer les impôts, il faut un lien entre ces boîtes noires : le montant des salaires est nécessaire pour calculer les impôts ) ;

Les liens entre les boîtes noires doivent être aussi simples que possible pour assurer l'indépendance entre elles.

La deuxième idée importante derrière les méthodes structurelles est l'idée de hiérarchie. Pour comprendre un système complexe, il ne suffit pas de le décomposer en parties, il faut organiser ces parties d'une certaine manière, à savoir sous forme de structures hiérarchiques. Tous les systèmes complexes de l'Univers sont organisés en hiérarchies. Oui, et il comprend lui-même les galaxies, les systèmes stellaires, les planètes, les molécules, les atomes, les particules élémentaires. Lors de la création de systèmes complexes, une personne imite également la nature. Toute organisation a un directeur, des adjoints pour les zones, une hiérarchie de chefs de département et des employés ordinaires. Ainsi, le deuxième principe de l'analyse structurelle (le principe d'ordre hiérarchique), outre le fait qu'il est plus facile de comprendre le problème s'il est décomposé en parties, déclare que l'agencement de ces parties est également essentiel pour la compréhension. La compréhensibilité d'un problème augmente considérablement lorsque ses parties sont organisées en structures hiérarchiques arborescentes, c'est-à-dire que le système peut être compris et construit sur des niveaux, chacun ajoutant de nouveaux détails.

Enfin, le troisième principe : les méthodes structurales font largement appel aux notations graphiques, servant également à faciliter la compréhension des systèmes complexes. Il est bien connu qu'"une image vaut mille mots".

Le respect de ces principes est nécessaire lors de l'organisation du travail aux premières étapes du cycle de vie, quels que soient le type de système développé et les méthodologies utilisées. La gestion de tous les principes dans un complexe permet plus étapes préliminaires développement pour comprendre à quoi ressemblera le système en cours de création, pour détecter les erreurs et les lacunes, ce qui, à son tour, facilitera le travail aux étapes ultérieures du cycle de vie et réduira le coût du développement.

Pour les besoins de l'analyse structurelle, trois groupes d'outils sont traditionnellement utilisés, illustrant :

les fonctions que le système doit remplir,

les relations entre les données

comportement du système en fonction du temps (aspects temps réel).

Parmi la variété de notations graphiques utilisées pour résoudre les problèmes ci-dessus, les suivantes sont le plus souvent et efficacement utilisées dans les méthodologies d'analyse structurelle :

DFD(Diagrammes de flux de données) - diagrammes de flux de données ensemble avec dictionnaires de données et spécifications de processus (mini-spécifications);

DRE(Diagrammes Entité-Relation) - diagrammes"essence-lien»;

MST(Diagrammes de transition d'état) - diagrammes de transition d'état.

Le DFD classique montre les sources et les puits de données (destinations) externes au système, identifie les fonctions logiques (processus) et les groupes d'éléments de données qui relient une fonction à une autre (flux), et identifie également les stockages de données (accumulateurs) auxquels on accède. Les structures de flux de données et leurs définitions de composants sont stockées et analysées dans le dictionnaire de données. Chaque fonction logique (processus) peut être détaillée à l'aide du DFD de niveau inférieur ; lorsque plus de détails ne sont plus utiles, on passe à l'expression de la logique de la fonction à l'aide d'une spécification de processus (mini-spécification). Le contenu de chaque magasin est également stocké dans un dictionnaire de données, le modèle de données du magasin est exposé à l'aide de l'ERD. Dans le cas du temps réel, DFD est complété par la description du comportement dépendant du temps du système, qui est révélé à l'aide de STD. Ces relations sont représentées sur la fig. vingt.

Il convient de noter que pour la modélisation fonctionnelle, avec DFD, une autre notation est souvent utilisée - SADT (plus précisément, son sous-ensemble standardisé IDEFO). Une analyse comparative de ces deux approches de modélisation des fonctions du système sera donnée ci-dessous.

Ainsi, les outils listés ci-dessus permettent de faire Description complète système, qu'il existe ou qu'il soit développé à partir de zéro. Cette description détaillée de ce que le système doit faire, affranchie autant que possible de la considération des chemins de mise en œuvre, est appelée la spécification des exigences, qui donne au concepteur mettant en œuvre la prochaine étape du cycle de vie une idée claire des résultats finaux. à atteindre.

Les notations graphiques énumérées ci-dessus sont utilisées (dans un ensemble ou un autre) dans presque toutes les méthodologies modernes d'analyse des systèmes structurels. Le rôle de ces méthodologies est de réguler les fondements du développement de systèmes complexes. Ils décrivent la séquence d'étapes, les modèles et

Riz. vingt

approches qui, si elles sont soigneusement suivies, conduiront à des systèmes qui fonctionnent bien. Bien que les méthodologies ne garantissent généralement pas la qualité des systèmes construits, elles permettent néanmoins de couvrir et de prendre en compte toutes les étapes, étapes et moments importants du développement, aident à faire face aux problèmes dimensionnels et, in fine, à évaluer les progrès. De plus, les méthodologies fournissent un support organisationnel qui permet à de grandes équipes de développeurs de fonctionner de manière coordonnée.

En d'autres termes, la méthodologie d'analyse structurelle définit les lignes directrices pour la construction et l'évaluation du modèle d'exigences du système en cours de développement, les étapes de travail à effectuer, leur séquence, ainsi que les règles de répartition et d'affectation des opérations et des méthodes utilisées. dans ce.

Actuellement, presque toutes les méthodologies connues d'analyse structurelle sont utilisées avec succès, cependant, les méthodologies les plus largement utilisées sont SADT (Structured Analysis and Design Technique), Gane-Sarson structural system analysis, Yourdon-DeMarko structural analysis and design. ), le développement de Systèmes Jackson (Jackson), développement de systèmes structuraux Warne-Orr (Warmer-Orr), analyse et conception de systèmes temps réel Ward-Mellor (Ward-Mellor) et Hatley (Hatley), modélisation de l'information Martin (Martin).

Les méthodologies structurelles énumérées réglementent strictement les phases d'analyse des exigences et de conception des spécifications et reflètent l'approche du développement du système du point de vue des recettes de "livre de cuisine". Les spécifications des exigences incluent les fonctionnalités du système cible et les performances prévues, les conceptions d'interface utilisateur (menus, écrans et formulaires), les critères d'intégrité du système, les environnements logiciels et matériels. Le document de spécification des exigences qui en résulte est ensuite converti en spécifications de conception détaillant la mise en œuvre prévue du FC. Les spécifications de conception identifient les principaux modules, les voies de communication et de contrôle entre les modules, les principaux sous-programmes au sein de chaque module, les structures de données, les spécifications de format de fichier d'entrée et de sortie. Pour les processus clés, les spécifications de conception incluent souvent les détails des algorithmes dans le langage de conception des mini-spécifications. À l'avenir, les méthodologies structurelles offriront une technique pour traduire les spécifications de conception en codes de programme. La génération de code implique l'existence de normes de code qui spécifient le format des en-têtes de sous-programmes, la forme étagée des blocs imbriqués, la nomenclature pour spécifier les variables et les noms de sous-programmes, etc.

Les méthodologies structurelles modernes sont classées selon les trois critères suivants :

surrelationàécoles - Génie logiciel (SE) etIngénierie de l'information (IE);

dans l'ordre de construction du modèle - orienté procédural et orienté information ;

taper systèmes cibles - pour les systèmes temps réel (RTS) et les systèmes d'information (SI).

SE est une discipline universelle pour le développement de systèmes logiciels de tous types (IS, RTS). IE est une discipline de construction des SI en général, et pas seulement de leurs composants logiciels, et comprend des étapes de niveau supérieur (par exemple, la planification stratégique), cependant, au stade de l'analyse des besoins pour la partie logicielle, ces disciplines sont similaires.

L'approche traditionnelle orientée procédures régule la primauté de la conception des composants fonctionnels par rapport à la conception des structures de données : les exigences de données sont révélées à travers les exigences fonctionnelles. Avec une approche orientée information, l'entrée et la sortie sont les plus importantes - les structures de données sont définies en premier, et les composants procéduraux sont dérivés de ceux donnés.

La principale caractéristique des systèmes en temps réel est qu'ils sont contrôlés et contrôlés par des événements externes; répondre à ces événements à temps est la fonction principale et primordiale de ces systèmes. Les différences fondamentales entre les systèmes d'information et les systèmes en temps réel sont indiquées dans le tableau. 2 ;

Tableau 2

En prenant en charge ces caractéristiques, les méthodologies structurelles correspondantes diffèrent. Il convient de noter que pour les besoins de l'analyse des exigences des systèmes temps réel, des types particuliers de diagrammes structurels sont utilisés : diagrammes de flux de contrôle, diagrammes de transition d'état, matrices d'état/événement, tables de décision, etc. Cependant, beaucoup d'entre eux sont des variantes. de schémas de structure pour l'analyse des besoins des systèmes d'information. De plus, les méthodologies bien connues d'analyse et de conception de RTS (en particulier, les méthodologies de Hutley et Ward-da-Mellore) sont basées sur les méthodologies ci-dessus pour l'analyse et la conception de SI, en les élargissant avec des techniques de diagramme appropriées.

En tableau. Le tableau 3 montre la classification des méthodologies les plus couramment utilisées selon les caractéristiques ci-dessus (les données sur la fréquence d'utilisation ont été obtenues à partir de l'analyse des informations sur 127 paquets CASE).

Comme déjà noté, la différence la plus significative entre les variétés d'analyse structurelle réside dans les méthodes et les moyens de modélisation fonctionnelle. De ce point de vue, toutes les variétés d'analyse des systèmes structurels peuvent être divisées en deux groupes : celles qui utilisent les méthodes et la technologie DFD (dans diverses notations) et celles qui utilisent la méthodologie SADT. Selon les documents de la société de recherche la plus autorisée dans le domaine considéré, CASE Consulting Group, le rapport d'utilisation de ces deux types d'analyse structurelle dans la pratique est de 90% pour DFD et de 10% pour SADT.

Tableau 3

Méthodologies	Fréquence d'utilisation	École	Ordre de construction	Type de systèmes cibles
Jodan De Marco			orienté procédural
Gein-Sarson			orienté procédural
Constantin			orienté procédural
			axé sur l'information
Warnier-Orr			axé sur l'information
			axé sur l'information
			orienté procédural

anticipant analyse comparative des approches DFD et SADT , à titre d'exemple, considérons le niveau supérieur du modèle d'exigences pour le système d'automatisation pour la gestion d'une entreprise engagée dans la distribution de marchandises par commandes (Fig. 21 et Fig. 22, respectivement). Les commandes font l'objet d'un contrôle à l'arrivée et d'un tri. Si la commande ne correspond pas à la gamme de produits ou est mal exécutée, elle est annulée avec la notification appropriée du client. Si la commande n'est pas annulée, il est déterminé si l'article correspondant est en stock. En cas de réponse positive, une facture de paiement est émise et présentée au client, dès réception du paiement, la marchandise est envoyée au client. Si la commande n'est pas fournie avec des stocks d'entrepôt, une demande pour les marchandises est envoyée au fabricant. Une fois que les marchandises requises sont arrivées à l'entrepôt de l'entreprise, la commande devient sécurisée et répète l'itinéraire décrit ci-dessus.

Une analyse comparative de ces deux types de méthodologies est effectuée selon les paramètres suivants:

l'adéquation des moyens au problème considéré ;

cohérence avec d'autres moyens d'analyse structurelle;

intégration avec les étapes ultérieures de développement (et surtout avec la phase de conception).

1) Adéquation. Le choix de l'une ou l'autre méthodologie structurelle dépend directement du domaine pour lequel le modèle est créé. Dans notre cas, les méthodologies sont appliquées aux systèmes de contrôle d'entreprise automatisés, et non aux systèmes en général, comme cela est supposé dans SADT. Pour les problèmes considérés, DFD est hors compétition.

Premièrement, les diagrammes SADT sont beaucoup moins expressifs et pratiques pour modéliser des systèmes de contrôle automatisés (comparer Fig. 21 et Fig. 22). Ainsi, les arcs dans SADT sont typés de manière rigide (entrée, sortie, contrôle, mécanisme). Dans le même temps, par rapport aux systèmes de contrôle automatisés, la différence sémantique entre entrées et sorties, d'une part, et contrôles et mécanismes, d'autre part, s'efface : entrées, sorties, mécanismes et contrôles sont des flux de données et/ou ou contrôles et les règles de leur transformation. Analyser un système avec des flux de données et les processus qui les transforment est plus transparent et sans ambiguïté.

systèmes (par exemple, les entrepôts de données sont des prototypes de fichiers ou de bases de données, les entités externes reflètent l'interaction du système modélisé avec le monde extérieur).

Deuxièmement, dans SADT, il n'y a pas de moyens expressifs pour modéliser les caractéristiques du système de contrôle automatisé. Dès le début, les DFD ont été créés comme un moyen de concevoir des systèmes d'information qui sont au cœur du système de contrôle automatisé, et ont un ensemble plus riche d'éléments qui reflètent adéquatement les spécificités des systèmes de troisième niveau ; la présence de mini-spécifications de Les processus DFD de bas niveau permettent de surmonter l'incomplétude logique de SADT de bas niveau, lorsque ses détails supplémentaires deviennent inutiles) et de construire une spécification fonctionnelle complète du système développé.

2) Cohérence. Le principal avantage de tous les modèles est la possibilité de leur intégration avec des modèles d'autres types. Dans ce cas, nous parlons de la cohérence des modèles fonctionnels avec les moyens de modélisation de l'information et de l'événement (temporel). Faire correspondre le modèle SADT avec ERD et/ou STD est presque impossible ou trivial. À leur tour, DFD, ERD et STD se complètent et sont essentiellement des représentations cohérentes de différents aspects du même modèle (voir Figure 20). En tableau. 4 montre la possibilité d'une telle intégration pour les modèles DFD et SADT.

Tableau 4

Nom			Cartes structurelles

Notez que l'intégration de DFD-STD est réalisée en étendant le DFD classique avec des outils spéciaux pour la conception de systèmes temps réel (processus de contrôle, flux, magasins de données), et STD est un détail du processus de contrôle, cohérent avec les flux de contrôle et magasins. L'intégration DFD-ERD est réalisée à l'aide d'un objet manquant dans SADT - stockage de données, dont la structure est décrite à l'aide d'ERD et est cohérente avec les flux correspondants et les autres stockages sur le DFD.

3) Intégration avec les étapes suivantes. Caractéristique importante méthodologie - sa compatibilité avec les étapes ultérieures d'application des résultats de l'analyse (et, surtout, avec l'étape de conception suivant immédiatement l'analyse et basée sur ses résultats). Les DFD peuvent être facilement convertis en modèles de conception (cartes structurelles) - ce sont des modèles étroitement liés. De plus, un certain nombre d'algorithmes de transformation automatique de la hiérarchie DFD en cartes structurelles sont connus. diverses sortes, qui fournit une transition logique et sans douleur de l'analyse des exigences à la conception du système. D'autre part, il n'existe aucune méthode formelle connue pour convertir les diagrammes SADT en solutions de conception APCS.

Néanmoins, il convient de noter que les variétés d'analyse structurelle considérées sont essentiellement deux langues d'environ la même puissance pour transmettre la compréhension. Et l'un des principaux critères de sélection est le suivant : la maîtrise de chacune de ces langues par un consultant ou un analyste, sa capacité à exprimer sa pensée dans cette langue.