Cycle de vie des systèmes d'information. Cycle de vie du SI et sa structure

Le cycle de vie d'un système d'information est une période de temps qui commence à partir du moment où une décision est prise sur la nécessité de créer un système d'information et se termine au moment de sa mise hors service complète.

Concept cycle de vie est l'un des concepts de base de la méthodologie de conception des systèmes d'information.

La méthodologie de conception des systèmes d'information décrit le processus de création et de maintenance des systèmes sous la forme d'un cycle de vie du SI (LC), le présentant comme une certaine séquence d'étapes et de processus exécutés sur ceux-ci. Pour chaque étape, la composition et la séquence des travaux effectués, les résultats obtenus, les méthodes et moyens nécessaires à la réalisation des travaux, les rôles et responsabilités des participants, etc. sont déterminés. Une telle description formelle du cycle de vie d'un système d'information permet de planifier et d'organiser le processus de développement collectif et d'assurer la gestion de ce processus.

Le cycle de vie complet d'un système d'information comprend généralement planification stratégique, analyse, conception, réalisation, mise en œuvre et exploitation. En général, le cycle de vie peut à son tour être divisé en plusieurs étapes. En principe, cette division en étapes est tout à fait arbitraire. Nous examinerons l'une des options pour une telle division, proposée par Rational Software Corporation, l'une des sociétés leaders sur le marché des logiciels d'outils de développement de systèmes d'information (parmi lesquels l'outil universel CASE Rational Rose est à juste titre très populaire).

Étapes du cycle de vie de la propriété intellectuelle

L'étape fait partie du processus de création d'une IP, limité par un certain laps de temps et se terminant par la sortie d'un produit spécifique (modèles, composants logiciels, documentation), déterminé par les exigences spécifiées pour cette étape. La relation entre les processus et les étapes est également déterminée par le modèle de cycle de vie du SI utilisé.

Selon la méthodologie proposée par Rational Software, le cycle de vie d'un système d'information se divise en quatre étapes.

Les limites de chaque étape sont définies par certains moments auxquels certaines décisions critiques doivent être prises et, par conséquent, certains objectifs clés doivent être atteints.

1) Étape initiale

Sur stade initial le champ d'application du système est établi et les conditions aux limites sont déterminées. Pour ce faire, il est nécessaire d'identifier tous les objets externes avec lesquels le système développé doit interagir, et de déterminer la nature de cette interaction à un niveau élevé. Au stade initial, toutes les fonctionnalités du système sont identifiées et les plus importantes d'entre elles sont décrites.

2) Étape de clarification

Au stade de la clarification, une analyse du domaine d'application est réalisée et les bases architecturales du système d'information sont élaborées.

Lors de la prise de décisions concernant l'architecture du système, il est nécessaire de prendre en compte le système en cours de développement dans son ensemble. Cela signifie qu'il est nécessaire de décrire la plupart Fonctionnalité système et prendre en compte les relations entre ses composants individuels.

A l'issue de l'étape de clarification, une analyse est réalisée solutions architecturales et les moyens d'éliminer les principaux facteurs de risque du projet.

3) Étape de construction

Au stade de la conception, un produit fini est développé, prêt à être livré à l'utilisateur.

A la fin de cette étape, les performances du logiciel développé sont déterminées.

4) Étape de mise en service

Au stade de la mise en service, le logiciel développé est transféré aux utilisateurs. Lors de l'exploitation d'un système développé dans des conditions réelles, divers types de problèmes surviennent souvent qui nécessitent un travail supplémentaire pour apporter des ajustements au produit développé. Ceci est généralement associé à la détection d’erreurs et de lacunes.

A l’issue de la phase de mise en service, il convient de déterminer si les objectifs de développement ont été atteints ou non.

Normes de cycle de vie de la propriété intellectuelle

Les réseaux modernes se développent sur la base de normes, ce qui permet d'assurer, d'une part, leur haute efficacité et, deuxièmement, la possibilité de leur interaction les uns avec les autres.

Parmi les normes les plus connues figurent les suivantes :

GOST 34.601-90 - s'applique aux systèmes automatisés et établit les étapes et étapes de leur création. De plus, la norme contient une description du contenu du travail à chaque étape. Les étapes et étapes de travail inscrites dans la norme sont plus cohérentes avec le modèle de cycle de vie en cascade.

ISO/IEC 12207 (Organisation internationale de normalisation / Commission électrotechnique internationale) 1995 - norme pour les processus et l'organisation du cycle de vie. S'applique à tous les types de logiciels personnalisés. La norme ne contient pas de descriptions des phases, des étapes et des étapes.

Le Rational Unified Process (RUP) propose un modèle de développement itératif qui comprend quatre phases : démarrer, explorer, créer et mettre en œuvre. Chaque phase peut être décomposée en étapes (itérations) qui aboutissent à la publication d'une version pour un usage interne ou externe. La progression à travers quatre phases principales est appelée un cycle de développement, chaque cycle se terminant par la génération d'une version du système. Si le travail sur le projet ne s'arrête pas après cela, le produit résultant continue de se développer et passe à nouveau par les mêmes phases. L'essence du travail au sein de RUP est la création et la maintenance de modèles basés sur UML.

Microsoft Solution Framework (MSF) est similaire à RUP, il comprend également quatre phases : analyse, conception, développement, stabilisation, il est itératif, et implique l'utilisation de modélisation orientée objet. MSF, par rapport à RUP, se concentre davantage sur le développement d'applications métiers.

Programmation extrême (XP). La programmation extrême (la plus récente parmi les méthodologies considérées) a été créée en 1996. La méthodologie est basée sur le travail d'équipe, une communication efficace entre le client et l'entrepreneur tout au long du projet de développement IP, et le développement est réalisé à l'aide de prototypes successivement affinés.

cascade du cycle de vie en spirale

ZCIS est la période de création et d'utilisation des systèmes d'information, commençant à partir du moment où le besoin de systèmes d'information se fait sentir et se terminant au moment de son déclassement complet.

Le cycle de vie est un modèle de création et d'utilisation d'un logiciel, reflétant ses différents états, commençant à partir du moment où le besoin d'un produit logiciel donné 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;
• conception;
• codage (programmation);
• tests et débogage ;
• opération et maintenance.

Étapes du cycle de vie du système d'information

1. Enquête avant-projet
   • 1.1. Collection de matériaux pour la conception ; Parallèlement, la formulation des exigences, l'étude de l'objet d'automatisation sont mises en avant et les conclusions préliminaires de la version de pré-conception du SI sont données.
   • 1.2. Analyse des matériaux et élaboration de la documentation ; une étude de faisabilité avec spécifications techniques pour Conception de circuits intégrés.
2. Conception
   • 2.1. Conception preliminaire:
     • sélection de solutions de conception sur les aspects du développement du SI ;
     • description des composants réels du SI ;
     • enregistrement et approbation projet technique(TP).
   • 2.2. Conception détaillée:
     • sélection ou développement méthodes mathématiques ou des algorithmes de programme ;
     • mise à jour des structures de bases de données ;
     • création de la documentation pour la livraison et l'installation produits logiciels;
     • sélection d'un ensemble de moyens techniques avec documentation pour son installation.
   • 2.3. Développement d'un projet technique et fonctionnel d'IP (TRP).
   • 2.4. Développement d'une méthodologie de mise en œuvre des fonctions de gestion à l'aide du SI et d'une description de la réglementation des actions de l'appareil de gestion.
3. Développement de la propriété intellectuelle
   • obtenir et installer du matériel et des logiciels ;
   • tester et peaufiner le progiciel ;
   • élaboration d'instructions d'exploitation pour logiciels et matériels.
4. Mise en service du SI
   • introduction de moyens techniques;
   • saisie de logiciels;
   • formation et certification du personnel;
   • opération d'essai;
   • remise et signature des actes de réception des travaux.
5. Fonctionnement IP
   • usage 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, depuis les plus anciennes, sont répétées cycliquement en fonction de l'évolution des exigences et des conditions extérieures, 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é ; De plus, pour chaque étape, les documents et décisions obtenus à l'étape précédente constituent les points de départ. 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/IEC 12207 (ISO - Organisation internationale de normalisation, CEI - Commission électrotechnique internationale). Il définit la structure du cycle de vie contenant les processus, activités et tâches qui doivent être effectués lors de la création d'un logiciel.

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

• principaux processus du cycle de vie du logiciel (achat, fourniture, développement, exploitation, support) ;
• 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 leurs composants conformément aux exigences spécifiées. Cela comprend la préparation de la documentation de conception et d'exploitation, la préparation du matériel nécessaire aux tests d'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 associée aux questions de planification et d'organisation du travail, de création d'équipes de développement et de suivi du calendrier et de la qualité du travail effectué. L'accompagnement technique et organisationnel du projet comprend la sélection de méthodes et d'outils pour la mise en œuvre du projet, la détermination de méthodes de description des états de développement intermédiaires, le développement de méthodes et d'outils de tests logiciels, la formation du personnel, etc. Assurer la qualité des projets est associé à des problèmes de vérification, de vérification et de test des logiciels.

La vérification est le processus permettant de déterminer si l'état actuel de développement atteint à un stade donné répond aux exigences de ce stade. La vérification 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 caractéristiques du logiciel répondent aux exigences initiales. Pendant la mise en œuvre du projet place importante concernent l'identification, la description et le contrôle de la configuration des composants individuels et de l'ensemble du système dans son ensemble.

La gestion de la configuration est l'un des processus auxiliaires qui prennent en charge les principaux processus du cycle de vie des logiciels, principalement les processus de développement et de maintenance des logiciels. Lors de la création de projets SI complexes composés de nombreux composants, chacun pouvant avoir des variétés ou des versions, le problème se pose de prendre en compte leurs connexions et fonctions, de créer une structure unifiée et d'assurer le développement de l'ensemble du système. La gestion de la configuration permet d'organiser, de prendre en compte et de contrôler systématiquement les évolutions des logiciels à toutes les étapes du cycle de vie. Principes généraux et les recommandations en matière de comptabilité de configuration, de planification et de gestion de configuration logicielle 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 sont notamment 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 solutions de conception développées aux étapes précédentes.

Le cycle de vie n'est pas une période d'existence, mais un processus de changements d'état séquentiels, déterminé par le type d'impacts produits (R 50-605-80-93).

Le terme « cycle de vie d’un système » fait généralement référence à l’évolution d’un nouveau système en plusieurs étapes, y compris des étapes aussi importantes que la conception, le développement, la production, l’exploitation et le déclassement final :70.

Histoire du concept de cycle de vie

La notion de cycle de vie est apparue à la fin du XIXe siècle. comme un complexe d'idées, comprenant les idées d'hérédité et de développement au niveau des individus et des organismes, ainsi que l'adaptation, la survie et l'extinction au niveau d'espèces individuelles et de populations entières d'organismes vivants.

Modèles typiques de cycle de vie du système

Il n’existe pas de modèle de cycle de vie unique capable de satisfaire aux exigences de chaque tâche possible. Divers organismes de normalisation, agences gouvernementales et sociétés d'ingénierie publient leurs propres modèles et technologies qui peuvent être utilisés pour construire le modèle. Il est donc inapproprié de prétendre à l’existence d’un seul algorithme possible pour construire un modèle de cycle de vie.

Certains ingénieurs système suggèrent d'envisager un modèle de cycle de vie du système basé sur trois sources : le modèle de gestion logistique du ministère de la Défense (DoD) (DoD 5000.2), le modèle ISO/IEC 15288 et le modèle de la National Society of Professional Engineers (NSPE). ) :71.

Modèle de cycle de vie typique selon ISO/IEC 15288

Selon la norme, les processus et activités du cycle de vie sont définis, configurés de manière appropriée et utilisés au cours d'une étape du cycle de vie pour satisfaire pleinement les objectifs et les résultats de cette étape. Différentes organisations peuvent être impliquées à différentes étapes du cycle de vie. Il n’existe pas de modèle universel unique pour les cycles de vie des systèmes. Certaines étapes du cycle de vie peuvent être absentes ou présentes selon chaque cas spécifique de développement du système34 :

La norme donne comme exemples les étapes suivantes du cycle de vie :

1. L'idée.
2. Développement.
3. Production.
4. Application.
5. Support d'application.
6. Arrêt et radiation.

Il n'y a aucun exemple d'étapes du cycle de vie dans la version 2008 de la norme (ISO/IEC 15288:2008).

Modèle de cycle de vie typique selon le ministère américain de la Défense

Pour gérer les risques liés à l'utilisation de technologies avancées et minimiser les erreurs techniques ou de gestion coûteuses, le ministère américain de la Défense a élaboré des lignes directrices contenant tous les principes nécessaires au développement de systèmes. Ces principes sont inclus dans une liste spéciale de directives - DoD 5000.

Le modèle de cycle de vie d’un système de gestion logistique selon le Département américain de la Défense comprend cinq étapes :71 :

1. Analyse.
2. Développement de la technologie.
3. Ingénierie et développement de la production.
4. Production et déploiement.
5. Fonctionnement et accompagnement.

Modèle générique du cycle de vie du système de la National Society of Professional Engineers (NSPE)

Ce modèle est adapté pour le développement de systèmes commerciaux. Ce modèle vise principalement le développement de nouveaux produits, généralement issus de Le progrès technique. Le modèle NSPE fournit une vue alternative du modèle de version DoD. Le cycle de vie selon le modèle NSPE est divisé en six étapes72 :

1. Concept.
2. Mise en œuvre technique.
3. Développement.
4. Validation commerciale et préparation de la production.
5. Production à grande échelle.
6. Support produit final.

Modèle typique du cycle de vie d'un produit selon R 50-605-80-93

Le document d'orientation R 50-605-80-93 étudie attentivement le cycle de vie d'un produit industriel, y compris les équipements militaires.

Pour les produits industriels à usage civil, les étapes suivantes sont proposées :

1. Recherche et conception.
2. Fabrication.
3. Appel et mise en œuvre.
4. Fonctionnement ou consommation.

Au sein du cycle de vie des produits industriels à usage civil, il est proposé de considérer 73 types de travaux et 23 types d'acteurs (« participants au travail » selon la terminologie du document).

Pour les produits industriels à usage militaire, les étapes suivantes sont proposées :

1. Recherche et justification du développement.
2. Développement.
3. Production.
4. Exploitation.
5. Rénovation majeure.

Dans le cycle de vie des produits militaro-industriels, il est proposé de considérer 25 types de travaux et 7 types d'acteurs (participants au travail).

Modèle typique de cycle de vie d'un logiciel

Les étapes du cycle de vie du système et leurs phases de composants, présentées dans la figure « Modèle de cycle de vie du système », s'appliquent aux systèmes les plus complexes, y compris ceux qui contiennent des logiciels avec une quantité importante de fonctionnalités au niveau des composants. Dans les systèmes à forte intensité logicielle dans lesquels les logiciels remplissent presque toutes les fonctions (comme dans les systèmes financiers modernes, les systèmes de réservation de billets d'avion, l'Internet mondial, etc.), en règle générale, les cycles de vie ont un contenu similaire, mais sont souvent compliqués par l'itération. processus et prototypage : 72-73.

Principales étapes du cycle de vie du système (Kossiakoff, Sweet, Seymour, Biemer)

Comme le montre la figure « Modèle de cycle de vie du système », le modèle de cycle de vie du système contient 3 étapes. Les 2 premières étapes se déroulent pendant le développement et la troisième étape couvre le post-développement. Ces étapes montrent des transitions plus générales d'un état à l'autre dans le cycle de vie d'un système, ainsi que des changements dans le type et la portée des activités impliquées dans l'ingénierie des systèmes. Les étapes sont les suivantes :73 :

• étape de développement du concept ;
• stade de développement technique;
• étape post-développement.

Étape de développement du concept

Le but de la phase de développement du concept est d'évaluer de nouvelles possibilités dans le domaine d'application du système, de développer des Configuration requise et les solutions de conception possibles. L'étape de développement de la conception conceptuelle commence par la prise de conscience de la nécessité de créer un nouveau système ou de modifier un système existant. L'étape comprend le début de la recherche factuelle, une période de planification et l'évaluation des bases économiques, techniques, stratégiques et commerciales des actions futures. Un dialogue s’instaure entre parties prenantes et promoteurs.

Principaux objectifs de la phase de développement du concept74 :

1. Mener des recherches pour déterminer ce qui est nécessaire pour le nouveau système, ainsi que la faisabilité technique et économique du système.
2. Explorez les concepts de système potentiels et formulez et validez un ensemble d'exigences de performances du système.
3. Sélectionnez le concept de système le plus attractif et définissez-le caractéristiques fonctionnelles, ainsi que d'élaborer un plan détaillé pour les étapes ultérieures de conception, de production et de déploiement opérationnel du système.
4. Développer n'importe quel nouvelle technologie adapté au concept de système choisi et valider sa capacité à répondre aux besoins.

Phase de développement technique

L'étape de développement technique implique le processus de conception d'un système pour mettre en œuvre les fonctions formulées dans le concept du système dans un mode de réalisation physique qui peut être pris en charge et exploité avec succès dans son environnement d'exploitation. L'ingénierie des systèmes consiste principalement à guider le développement et la conception, à gérer les interfaces, à élaborer des plans de test et à déterminer comment les écarts dans les performances d'un système non vérifiés lors des tests et de l'évaluation doivent être correctement corrigés. L'essentiel des activités d'ingénierie est réalisé à ce stade.

Les principaux objectifs de la phase de développement technique sont les suivants74 :

1. Effectuer le développement technique d'un prototype de système qui répond aux exigences de performance, de fiabilité, de maintenabilité et de sécurité.
2. Concevoir un système adapté à son utilisation et démontrer son adéquation opérationnelle.

Étape post-développement

La phase post-développement comprend des activités en dehors de la période de développement du système, mais nécessite néanmoins un soutien important de la part des ingénieurs système, en particulier lorsque des problèmes inattendus surgissent et nécessitent une résolution rapide. En outre, les progrès technologiques nécessitent souvent des mises à niveau des systèmes de service internes, qui peuvent dépendre autant de l’ingénierie des systèmes que des étapes de conception et de développement technique.

Travail de laboratoire n°1

Identification des cycles de vie de conception de systèmes informatiques

But du travail: se familiariser avec les modèles de cycle de vie des systèmes d'information, déterminer les avantages et les inconvénients des modèles, sélectionner un modèle de construction d'un système d'information pour une tâche de projet individuelle et un logiciel, établir un plan pour la mise en œuvre d'une tâche de projet individuelle.

Brèves informations théoriques.

Cycle de vie d'un système d'information

Le développement de systèmes d’information (SI) complexes est impossible sans une approche méthodologique mûrement réfléchie. La notion de cycle de vie est l'un des concepts de base de la méthodologie de conception des systèmes d'information.

Cycle de vie du SI –Il s'agit d'un processus continu depuis le moment où une décision est prise quant à la nécessité de créer une solution jusqu'à l'achèvement complet de son fonctionnement.

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

· GOST 34.601-90. Entré en vigueur le 01/01/1992. Établit les étapes et étapes de création de systèmes automatisés et donne le contenu du travail à chaque étape. Les étapes et étapes de travail inscrites dans la norme correspondent à modèle en cascade cycle de vie.

· ISO/CEI 12207:1995. Une norme internationale décrivant les processus du cycle de vie des logiciels. Contient une description de plus de 220 travaux de base qui peuvent être nécessaires dans le processus de création d'une propriété intellectuelle. Tous les processus du cycle de vie des logiciels sont divisés en trois grands groupes :

o Principaux processus (achat, approvisionnement, développement, exploitation, support) ;

o Processus d'assistance(documentation, gestion de configuration, assurance qualité, résolution de problèmes, audit, certification, évaluation conjointe, vérification) ;

o Processus organisationnels (création d'infrastructures, gestion, formation, amélioration).

Pour mettre en œuvre les dispositions de la norme, il faut sélectionner des outils qui forment ensemble un complexe interconnecté de support technologique et d'automatisation du cycle de vie du logiciel et ne contredisent pas l'ensemble pré-assemblé documents réglementaires. Faciliter utilisation pratique norme, les documents suivants ont été élaborés et approuvés par l'organisation internationale de normalisation :

o ISO/IEC TR 15271:1998 – lignes directrices sur l'application de l'ISO/IEC 12207 ;

o ISO/IEC TR 16326:1999 – lignes directrices sur la gestion de projet lors de l'utilisation de l'ISO/IEC 12207.

· ISO/CEI 15288:2002. Norme internationale décrivant processus possibles cycle de vie des systèmes créés par l'homme. Il a été créé en tenant compte de l'expérience dans la conception de systèmes d'information automatisés, ainsi qu'avec la participation de spécialistes de divers domaines : ingénierie des systèmes, programmation, administration, gestion de la qualité, sécurité, etc. La norme est destinée à contenir l'ensemble complet des processus pouvant survenir au cours du cycle de vie d'un système. Ainsi, la tâche du développeur SI est de créer l'ensemble dont il a besoin - l'environnement de processus. L'examen de la norme indique qu'elle ne décrit pas les méthodes et procédures nécessaires pour garantir que les buts, objectifs et résultats des processus spécifiés sont atteints. En 2003, des lignes directrices sur l'application de la norme (ISO/IEC TR 19760:2003) ont été publiées. Actuellement, les travaux se poursuivent sur la préparation d'une nouvelle édition de la norme de la série 15288.

· Rational Unified Process (RUP) est un concept de développement logiciel itératif (en spirale) proposé par Rational Software (maintenant une division d'IBM). Le cycle de vie du SI se compose de quatre phases : création, recherche, construction et transition. Chaque phase peut contenir plusieurs itérations. De plus, l'achèvement des quatre phases ne signifie pas toujours l'achèvement des travaux du projet - son développement peut se poursuivre dans un nouveau cycle. Dans le cadre des itérations, des modèles mutuellement cohérents sont créés, qui sont décrits dans un UML (Unified Modeling Language) spécialement développé.

· Cadre de solutions Microsoft (MSF). Méthodologie de développement d'applications itératives similaire à RUP. Il comprend également quatre phases : analyse, conception, développement, stabilisation et implique l'utilisation de la modélisation orientée objet. Par rapport au RUP, il est davantage axé sur le développement de la propriété intellectuelle pour les entreprises.

· Programmation extrême (XP). L'Extreme Programming est la plus récente parmi les méthodologies considérées (les premières idées ont été formulées au milieu des années 1990). Principes de base : travail d'équipe, interaction efficace entre le client et l'entrepreneur tout au long de la période de développement IP, utilisation de prototypes successivement affinés, obtention d'une flexibilité de développement maximale (adaptation aux exigences changeantes du client).

Modèles de cycle de vie du SI.

Le modèle de cycle de vie du SI est compris comme une structure qui détermine la séquence d'exécution et les relations entre les processus d'actions et de tâches tout au long du cycle de vie.

Modèle de cycle de vie de la propriété intellectuelle- Il s'agit d'une structure qui décrit les processus, actions et tâches effectués pendant le développement, l'exploitation et la maintenance tout au long du cycle de vie du système.

Le choix d'un modèle de cycle de vie dépend des spécificités, de l'échelle, de la complexité du projet et de l'ensemble des conditions dans lesquelles l'AIS est créé et fonctionne.

Conformément à modèles célèbres Les cycles de vie des logiciels sont déterminés par les modèles de cycle de vie du SI - en cascade, itératif, en spirale.

I. Modèle en cascade décrit l'approche classique du développement de systèmes dans n'importe quel domaine ; largement utilisé dans les années 70 et 80.

Le modèle en cascade prévoit une organisation séquentielle du travail et la principale caractéristique du modèle est la division de tous les travaux en étapes. Le passage de l'étape précédente à la suivante n'intervient qu'après l'achèvement complet de tous les travaux de la précédente.

Souligner cinq étapes de développement durables, pratiquement indépendantes du domaine :

Dans un premier temps, une étude de la problématique est réalisée et les exigences du client sont formulées. Le résultat de cette étape est une spécification technique (tâche de développement) convenue avec toutes les parties intéressées.

Au cours de la deuxième étape, conformément aux exigences du cahier des charges, certaines solutions de conception sont développées. Le résultat est un ensemble documentation du projet.

La troisième étape est la mise en œuvre du projet ; Essentiellement, le développement de logiciels (codage) conformément aux décisions de conception de l'étape précédente. Les modalités de mise en œuvre ne revêtent pas ici une importance fondamentale. Le résultat de cette étape est un produit logiciel fini.

Lors de la quatrième étape, le logiciel résultant est vérifié pour sa conformité aux exigences énoncées dans les spécifications techniques. L'exploitation expérimentale permet d'identifier diverses sortes de défauts cachés qui apparaissent dans les conditions réelles de fonctionnement du SI.

La dernière étape est la livraison du projet fini.

A chaque étape, un ensemble complet de documentation de conception est généré qui répond aux critères d'exhaustivité et de cohérence. Aux étapes finales, une documentation utilisateur est élaborée, couvrant tous les types de support AIS prévus par les normes (organisationnelles, informationnelles, logicielles, techniques, etc.). L'exécution cohérente des étapes de travail vous permet de planifier les dates d'achèvement et les coûts associés.

Dans le même temps, pour le modèle en cascade, il faut noter un retard important dans l'obtention des résultats, la complexité des travaux parallèles sur le projet et la complexité de la gestion du projet, et par conséquent, un niveau de risque élevé et un manque de fiabilité de investissements dans la propriété intellectuelle. De plus, des erreurs et des lacunes apparaissent à n'importe quelle étape, en règle générale, aux étapes ultérieures du travail, ce qui entraîne la nécessité d'un retour.

II. Modèle itératif se situe dans la série cycles courts(étapes) pour planifier, mettre en œuvre, étudier, agir. Le développement du SI est en cours itérations avec des boucles de rétroaction entre les étapes. Les ajustements inter-étapes permettent de prendre en compte l'influence mutuelle réelle des résultats de développement aux différentes étapes ; La durée de vie de chaque étape s'étend sur toute la période de développement.

La création de systèmes d'information complexes implique la coordination des solutions de conception obtenues lors de la mise en œuvre de tâches individuelles. L'approche « ascendante » de la conception nécessite de telles itérations de résultats, lorsque les solutions de conception pour des tâches individuelles sont combinées dans celles du système général. Dans le même temps, il est nécessaire de réviser les exigences précédemment formulées.

Dans le modèle itératif, les ajustements entre les étapes garantissent un développement moins exigeant en main-d'œuvre par rapport au modèle en cascade.

Dans le même temps, la durée de vie de chaque étape est prolongée sur toute la durée des travaux, grâce à grand nombre itérations, des divergences surviennent dans la mise en œuvre des décisions de conception et de la documentation ; la nécessité de repenser l'ensemble du système peut survenir au stade de la mise en œuvre.

III. Modèle en spirale , contrairement à la cascade, mais similaire à la précédente, elle suppose un processus itératif de développement du SI. Dans le même temps, l'importance des étapes initiales, telles que l'analyse et la conception, augmente, au cours desquelles la faisabilité des solutions techniques est vérifiée et justifiée par la création de prototypes.

Chaque itération représente un cycle de développement complet, aboutissant à la sortie d'une version interne ou externe d'un produit (ou d'un sous-ensemble du produit final), qui est améliorée d'itération en itération pour devenir un système complet :

Ainsi, chaque tour de spirale correspond à la création d'un fragment ou d'une version d'un produit logiciel, les objectifs et les caractéristiques du projet sont clarifiés, sa qualité est déterminée et des travaux sont planifiés pour le prochain tour de spirale. Chaque itération sert à approfondir et à préciser systématiquement les détails du projet, ce qui permet de sélectionner une option raisonnable pour la mise en œuvre finale.

L'utilisation du modèle en spirale permet la transition vers étape suivante terminer un projet sans attendre que le projet en cours soit complètement terminé - le travail inachevé peut être terminé à l'itération suivante. La tâche principale de chaque itération est de créer un produit fonctionnel à démontrer aux utilisateurs le plus rapidement possible. Ainsi, le processus de clarification et d'ajout au projet est considérablement simplifié.

L'approche en spirale du développement logiciel surmonte la plupart des inconvénients du modèle en cascade et fournit également un certain nombre de fonctionnalités supplémentaires, rendant le processus de développement plus flexible. Lors de l'utilisation du modèle en spirale, il est considérablement simplifié d'apporter des modifications au projet lorsque les exigences du client changent, le niveau de risque est réduit (le niveau de risque est maximum au début du développement du projet, à mesure que le développement progresse, il diminue), une plus grande flexibilité la gestion de projet est assurée grâce à la possibilité d'apporter des modifications tactiques au produit développé, à la capacité d'améliorer le processus de développement - à la suite d'une analyse à la fin de chaque itération, une évaluation des changements dans l'organisation de développement est effectuée ; dans l'itération suivante, cela s'améliore, la réutilisation des composants devient plus facile, car il est beaucoup plus facile d'identifier les parties communes du projet lorsqu'elles sont déjà partiellement développées que d'essayer de les isoler au tout début du projet. Le modèle en spirale permet un système plus fiable et plus stable. En effet, à mesure que le système évolue, les erreurs et les faiblesses sont découvertes et corrigées à chaque itération. En même temps, ils sont ajustés paramètres critiques l'efficacité, qui dans le cas du modèle en cascade n'est disponible qu'avant la mise en œuvre du système. Impliquer les utilisateurs dans le processus de conception et de copie de l'application vous permet de recevoir des commentaires et des ajouts aux exigences directement pendant le processus de conception de l'application, réduisant ainsi le temps de développement. Les représentants des clients ont la possibilité de contrôler le processus de création du système et d'influencer son contenu fonctionnel. Le résultat est la mise en service d'un système qui prend en compte la majorité des besoins des clients.

Cependant, le modèle en spirale de conception de circuits intégrés a généralement un coût élevé (il est donc logique de l'utiliser pour des systèmes complexes et coûteux). Le modèle a structure complexe, ce qui peut rendre difficile son utilisation pratique par des spécialistes et des clients non formés. La spirale peut se poursuivre indéfiniment, puisque chaque réponse client à la version créée peut générer un nouveau cycle de travail. Un grand nombre d'étapes intermédiaires complique la maintenance de la documentation du projet. Il peut être difficile de déterminer quand passer à la prochaine itération du cycle. Généralement, des restrictions de temps sont imposées sur l'exécution de l'itération et de chacune de ses étapes.

Dans certaines situations, l'utilisation du modèle en spirale est impossible ou limitée, car il est impossible d'utiliser/tester un produit dont les fonctionnalités sont incomplètes (par exemple, développements militaires, Pouvoir nucléaire etc.). La mise en œuvre itérative par étapes des systèmes d'information d'entreprise est généralement associée à des difficultés organisationnelles (transfert de données, intégration des systèmes, modifications des processus métiers, politiques comptables, formation des utilisateurs). Les coûts de main-d'œuvre lors de la mise en œuvre itérative étape par étape s'avèrent beaucoup plus élevés, et une gestion analphabète du processus de mise en œuvre peut annuler tous les résultats obtenus. Pour cette raison, au stade de la mise en œuvre, on renonce souvent aux modèles itératifs, introduisant le système « une fois pour toutes ».

©2015-2019site
Tous les droits appartiennent à leurs auteurs. Ce site ne revendique pas la paternité, mais propose une utilisation gratuite.
Date de création de la page : 2016-04-27

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 du système, les concepts suivants sont utilisés :

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

étapes - périodes successives pendant lesquelles le travail est effectué . Au cours de cette étape, des travaux liés à différents processus peuvent être effectués. L'activité de création et d'utilisation d'un système de gestion d'entreprise automatisé (EMS) repose sur la notion de son cycle de vie (LC). Le cycle de vie est un modèle de création et d'utilisation de systèmes de contrôle automatisés, reflétant ses différents états, commençant à partir du moment où le besoin d'un produit donné se fait sentir et se terminant par le moment de son obsolescence complète pour tous les utilisateurs sans exception.

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

analyse des besoins;

conception;

programmation/mise en œuvre ;

tests et débogage ;

opération et maintenance.

Le cycle de vie est formé selon le principe de conception descendante et, en règle générale, est de nature itérative : les étapes mises en œuvre, en commençant par la plus ancienne, sont répétées cycliquement en fonction de l'évolution des exigences et des conditions externes, l'introduction des restrictions, etc. A chaque étape du cycle de vie, un certain ensemble de documents et de solutions techniques est généré, et pour chaque étape, les documents initiaux et les décisions obtenues à l'étape précédente sont utilisés. 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 transition 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 une transition vers l'étape suivante après l'achèvement complet des travaux sur l'étape précédente et se caractérise par une séparation claire des données et de leurs processus de 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 fournissent moins d'intensité de travail que le modèle en cascade ; en revanche, la durée de vie de chaque étape s'étend 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 création de prototypes. Chaque tour de spirale correspond à un modèle étape par étape pour créer un fragment ou une version du système ; sur celui-ci, les objectifs et les caractéristiques du projet sont clarifiés, sa qualité est déterminée et le travail du prochain tour de la spirale est prévue. De cette manière, les détails du projet sont approfondis et systématiquement précisés, 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 de logiciels, modèles et prototypes ;

orientation vers le développement et la modification du système en cours de conception ;

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

. Notez que la principale caractéristique de l'industrie des systèmes de contrôle automatisés est la concentration de la complexité sur étapes initiales Cycle de vie (analyse, conception) avec une complexité et une intensité de travail relativement faibles pour les étapes suivantes. De plus, les problèmes non résolus et les erreurs commises lors des étapes d’analyse et de conception donnent lieu à des problèmes difficiles, souvent insolubles, aux étapes ultérieures et peuvent, en fin de compte, faire dérailler le succès.

Analyse des besoins

L'analyse des besoins est la première phase du développement d'un système de contrôle automatisé, au cours de laquelle les exigences des clients sont clarifiées, formalisées et documentées. En effet, à ce stade, la réponse à la question est donnée : « Que devra faire le futur système ? C’est là que réside la clé du succès 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 projets infructueux précisément en raison du caractère incomplet et de la définition peu claire des exigences du système.

La liste des exigences relatives aux systèmes de contrôle automatisés doit inclure :

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

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

Contraintes dans le processus de développement (délais directifs pour la réalisation des différentes étapes, ressources disponibles, procédures organisationnelles et mesures pour assurer la sécurité de l'information).

Le but de l'analyse est de transformer les connaissances générales 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 de configuration système requise (en d'autres termes, un projet système) , définissant :

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

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

Exigences relatives aux composants logiciels et informatifs du variateur de fréquence , ressources matérielles nécessaires, exigences en matière de base de données, caractéristiques physiques des composants de l'onduleur, leurs interfaces. Le modèle d'exigences doit inclure :

Un modèle fonctionnel complet des exigences du futur système avec une élaboration approfondie jusqu'au niveau de chaque opération de chaque fonctionnaire ;

Spécifications de fonctionnement de bas niveau ;

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

Modèle d'information conceptuel des exigences ;

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 ;

Propositions de structure organisationnelle pour soutenir le système.

Ainsi, le modèle d'exigences contient des modèles fonctionnels, informatifs 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 premières étapes à l’aide de méthodes artisanales et non formalisées. Ainsi, les clients et les utilisateurs peuvent voir le système pour la première fois alors qu'il est déjà largement mis en œuvre. Naturellement, ce système sera différent de ce à quoi ils s’attendaient. Par conséquent, plusieurs itérations supplémentaires de son développement ou de sa modification suivront, ce qui nécessitera des coûts supplémentaires (et importants) en argent et en temps. La clé pour résoudre ce problème est fournie par un modèle d’exigences qui vous permet de :

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

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

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

Parvenir à une compréhension mutuelle entre tous les participants aux travaux (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 aucune maintenance de la part de ses créateurs et peut être transféré sans douleur à d'autres. De plus, si, pour une raison quelconque, une entreprise n'est pas prête à mettre en œuvre un système basé sur un modèle d'exigences, il peut être mis « de côté » jusqu'à ce que le besoin s'en fasse sentir.

3. Le modèle d'exigences peut être utilisé pour le développement ou l'ajustement indépendant de logiciels déjà implémentés sur cette base par les programmeurs du service d'automatisation de l'entreprise.

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

L’étape d’analyse des besoins est la plus importante parmi toutes les étapes du cycle de vie. Il a un impact significatif sur toutes les étapes ultérieures, tout en étant 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 enregistré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.

En revanche, l’étape du cycle de vie considérée constitue 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 pour lesquelles ils sont difficiles à 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, quant à lui, ne dispose pas d'informations suffisantes sur le problème de traitement des données pour juger de ce qui est réalisable et de ce qui ne l'est pas ;

L'analyste est confronté à une quantité excessive d'informations détaillées sur le domaine et sur nouveau système;

La description traditionnelle (textuelle) du système est souvent incompréhensible pour le client en raison de la quantité de termes techniques ;

Si une telle spécification est claire pour le client, elle ne suffira pas aux concepteurs et aux programmeurs qui créent ou adaptent le système.

Bien entendu, l'utilisation de méthodes analytiques bien connues élimine les problèmes d'analyse individuels, mais une solution acceptable à l'ensemble de ces problèmes ne peut être trouvée que grâce à l'utilisation de méthodes modernes d'ingénierie système et logicielle, parmi lesquelles une place clé est occupée par les 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 un aperçu général de celui-ci puis entre dans les détails, en acquérant une structure hiérarchique avec un nombre croissant de niveaux. . Ces méthodes se caractérisent par :

Partitionnement en niveaux d'abstraction avec une limite sur le nombre d'éléments à chaque niveau (généralement de 3 à 7, la limite supérieure correspondant à la capacité du cerveau humain à percevoir une certaine quantité de objets interconnectés, et celui du bas a été choisi pour des raisons bon sens);

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

Utilisation de règles d'enregistrement formelles strictes ;

Se rapprocher constamment du résultat final.

Les méthodes d'analyse structurelle permettent de s'affranchir de la complexité des grands systèmes en les décomposant en parties (« boîtes noires ») et en organisant hiérarchiquement ces boîtes noires. . L’avantage d’utiliser une boîte noire est que l’utilisateur n’a pas besoin de connaître son fonctionnement, mais seulement ses entrées et sorties et son objectif (c’est-à-dire la fonction qu’elle remplit). Dans le monde qui nous entoure, on trouve des boîtes noires grandes quantités: magnétophone et télévision au niveau du foyer, une entreprise du point de vue du client, etc. Illustrons les avantages des systèmes qui en sont constitués à l’aide de l’exemple d’une centrale musicale.

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

Cela facilite le test de tels systèmes. Si le son de l'un des haut-parleurs est faible, vous pouvez échanger les haut-parleurs. Si le défaut s'est déplacé avec la colonne, alors c'est la colonne qu'il faut réparer ; sinon, le problème vient de l'amplificateur, du magnétophone ou de leurs points de connexion.

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

Facilite la compréhension et la maîtrise. Il est possible de devenir spécialiste du magnétophone sans connaissance approfondie des enceintes.

Améliore la facilité de modification. Vous pouvez acheter des enceintes pour plus de Haute qualité et un amplificateur plus puissant, mais cela ne signifie pas qu'un lecteur plus gros est nécessaire.

Ainsi, la première étape pour simplifier un système complexe consiste à le décomposer en boîtes noires (le principe « diviser pour régner » - le principe de résoudre des problèmes difficiles en les divisant en de nombreuses tâches indépendantes faciles à comprendre et à résoudre), et une telle division doit répondre aux critères suivants :

Chaque boîte noire doit mettre en œuvre 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 disposer d'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 connexion entre les boîtes noires ne doit être introduite 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 total). salaires salarié, et l'autre - pour calculer les impôts, une connexion entre ces boîtes noires est nécessaire : le montant du salaire est nécessaire pour calculer les impôts) ;

Les connexions entre boîtes noires doivent être les plus simples possibles pour garantir l’indépendance entre elles.

La deuxième idée importante qui sous-tend les méthodes structurelles est l'idée de hiérarchie. Pour comprendre un système complexe, il ne suffit pas de le diviser en parties, il faut organiser ces parties d'une certaine manière, notamment sous forme de structures hiérarchiques. Tous les systèmes complexes de l'Univers sont organisés en hiérarchies. Et il comprend lui-même les galaxies, les systèmes stellaires, les planètes, les molécules, les atomes et les particules élémentaires. En créant des systèmes complexes, l’homme imite également la nature. Toute organisation a un directeur, des adjoints par domaine, une hiérarchie de chefs de service et des employés ordinaires. Ainsi, le deuxième principe de l’analyse structurale (le principe d’ordre hiérarchique), outre le fait qu’il est plus facile de comprendre un problème s’il est décomposé en parties, déclare que la disposition de ces parties est également essentielle à 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 en niveaux, chacun ajoutant de nouveaux détails.

Enfin, troisième principe : les méthodes structurales font largement appel aux notations graphiques, servant également à faciliter la compréhension de systèmes complexes. On sait qu’« une image vaut mille mots ».

Le respect de ces principes est nécessaire lors de l'organisation du travail dès les premières étapes du cycle de vie, quel que soit le type de système développé et les méthodologies utilisées. Guidé par tous les principes dans un complexe permet plus étapes préliminaires développement pour comprendre à quoi ressemblera le système créé, 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 de développement.

Aux fins de l'analyse structurelle, trois groupes d'outils sont traditionnellement utilisés, illustrant :

fonctions que le système doit remplir,

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 répertoriés, les suivantes sont les 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) ;

DER(Diagrammes entité-relation) - diagrammes"essence-connexion»;

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

Un DFD classique affiche les sources et les récepteurs de données (destination) externes au système, identifie les fonctions logiques (processus) et les groupes d'éléments de données qui lient une fonction à une autre (threads), et identifie également les magasins de données (lecteurs) auxquels on accède. Les structures de flux de données et les définitions de leurs composants sont stockées et analysées dans un dictionnaire de données. Chaque fonction logique (processus) peut être détaillée à l'aide d'un DFD de niveau inférieur ; lorsque des détails supplémentaires ne sont plus utiles, passez à l'expression de la logique de la fonction à l'aide d'une spécification de processus (mini-spécification). Le contenu de chaque référentiel est également stocké dans un dictionnaire de données, le modèle de données du référentiel est exposé à l'aide d'ERD. Dans le cas du temps réel, DFD est complété par la description du comportement dépendant du temps du système, révélé par STD. Ces relations sont représentées sur la Fig. 20.

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

Ainsi, les outils listés ci-dessus vous permettent de faire Description complète systèmes, qu’ils soient existants ou en cours de développement. Cette description détaillée de ce que doit faire le système, libérée autant que possible de la considération des chemins de mise en œuvre, est appelée spécification des exigences, donnant au concepteur mettant en œuvre la prochaine étape du cycle de vie une idée claire des résultats finaux qui doivent être atteint.

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

Riz. 20

des approches qui, si elles sont soigneusement suivies, conduiront à des systèmes qui fonctionnent bien. Même si les méthodologies, d’une manière générale, ne garantissent 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 de dimensionnalité et, in fine, à évaluer les progrès. De plus, les méthodologies fournissent un soutien organisationnel qui permet aux grandes équipes de développement 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 à réaliser, leur séquence, ainsi que les règles de répartition et d'affectation des opérations et des méthodes. utilisé.

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

Les méthodologies structurelles répertoriées réglementent strictement les phases d’analyse des exigences et de conception des spécifications et reflètent une approche « livre de recettes » du développement de systèmes. Les spécifications des exigences incluent les fonctionnalités du système cible et ses caractéristiques prévues, les conceptions de l'interface utilisateur (menus, écrans et formulaires), les critères de performances du système, l'environnement logiciel et matériel. Le document de spécification des exigences qui en résulte est ensuite transformé en spécifications de conception détaillant la mise en œuvre prévue du variateur. Les spécifications de conception identifient les modules principaux, les routes de communication et de contrôle entre les modules, les principales routines au sein de chaque module, les structures de données et les spécifications des formats de fichiers d'entrée et de sortie. Pour les processus clés, les spécifications de conception incluent souvent les détails de l'algorithme dans un langage de conception de mini-spécifications. À l’avenir, les méthodologies structurelles offriront une technique permettant de traduire les spécifications de conception en codes de programme. La génération de code présuppose l'existence de standards de code précisant le format des en-têtes des sous-programmes, l'apparition échelonnée des blocs imbriqués, la nomenclature de spécification des variables et des noms des sous-programmes, etc.

Les méthodologies structurelles modernes sont classées selon les trois caractéristiques suivantes :

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

afin de construire le modèle - orienté procédure et orienté information ;

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

SE est une discipline universelle dans le développement de systèmes logiciels de tous types (IS, SRV). IE est la discipline de construction des SI en général, et pas seulement de leurs composants logiciels, et comprend des étapes de plus haut niveau(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 en matière de données se révèlent à travers les exigences fonctionnelles. Dans une approche centrée sur l'information, les entrées et les sorties sont les plus importantes : les structures de données sont définies en premier et les composants procéduraux sont dérivés des données.

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

Tableau 2

Les moyens de prendre en charge ces fonctionnalités distinguent les méthodologies structurelles correspondantes. Il convient de noter que pour analyser les besoins 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/d'événement, tables de décision, etc. Cependant, beaucoup d'entre eux sont des variantes. de schémas structurels pour l'analyse des besoins des systèmes d'information. De plus, les méthodologies bien connues d'analyse et de conception de CI (en particulier les méthodologies de Hutley et War da Mellor) sont basées sur les méthodologies répertoriées pour l'analyse et la conception de CI, en les élargissant avec les techniques de création de diagrammes correspondantes.

Dans le tableau La figure 3 montre la classification des méthodologies les plus couramment utilisées conformément aux critères ci-dessus (les données sur la fréquence d'utilisation ont été obtenues sur la base d'une analyse des informations sur 127 packages CASE).

Comme déjà indiqué, la différence la plus significative entre les types d'analyse structurelle réside dans les méthodes et outils de modélisation fonctionnelle. De ce point de vue, tous les types d'analyse de systèmes structurels peuvent être divisés en deux groupes : ceux utilisant les méthodes et la technologie DFD (dans diverses notations) et ceux utilisant la méthodologie SADT. Selon les documents de la société de recherche la plus réputée dans ce domaine, CASE Consulting Group, le ratio d'utilisation de ces deux types d'analyse structurelle dans la pratique est de 90 % pour DFD et de 10 % pour SADT.

Tableau 3

Anticipant analyse comparative des approches DFD et SADT , à titre d'exemple, considérons le niveau supérieur du modèle d'exigences pour un système d'automatisation de gestion pour une entreprise impliquée dans la distribution de marchandises selon les commandes (Fig. 21 et Fig. 22, respectivement). Les commandes sont soumises à une inspection et à un tri à l'arrivée. Si la commande ne correspond pas à la gamme de produits ou est mal passée, elle est annulée avec notification appropriée au client. Si la commande n'est pas annulée, il est déterminé si le produit correspondant est en stock. Si la réponse est 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 dotée de stocks d'entrepôt, alors une demande du produit est envoyée au fabricant. Une fois les marchandises requises arrivées à l'entrepôt de l'entreprise, la commande est 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 réalisée selon les paramètres suivants:

adéquation des fonds au problème considéré ;

cohérence avec d'autres outils 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 automatisés de gestion d’entreprise, et non aux systèmes en général, comme le suppose la SADT. Pour les problèmes considérés, DFD est sans égal.

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

certains 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 monde extérieur).

Deuxièmement, SADT manque généralement de moyens expressifs pour modéliser les caractéristiques des systèmes de contrôle automatisés. Les DFD ont été créés dès le début comme moyen de concevoir des systèmes d'information, qui sont au cœur des systèmes de contrôle automatisés, et disposent d'un ensemble plus riche d'éléments qui reflètent adéquatement les spécificités et, troisièmement, la présence de mini-spécifications de DFD de niveau inférieur. Les processus permettent de surmonter l'incomplétude logique de la SADT (à savoir la rupture du modèle à un niveau suffisamment bas, lorsque des détails supplémentaires n'ont plus de sens) et de construire une spécification fonctionnelle complète du système en cours de développement.

2) Cohérence. Le principal avantage de tout modèle est la possibilité de l’intégrer à d’autres types de modèles. Dans ce cas, nous parlons de la cohérence des modèles fonctionnels avec les outils de modélisation d'informations et d'événements (temporels). Réconcilier 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 des représentations essentiellement cohérentes de différents aspects du même modèle (voir Fig. 20). Dans le tableau La figure 4 montre la possibilité d'une telle intégration pour les modèles DFD et SADT.

Tableau 4

Notez que l'intégration de DFD-STD est réalisée en élargissant le DFD classique avec des outils spéciaux pour concevoir des systèmes en temps réel (processus de contrôle, threads, magasins de données), et STD est un détail du processus de contrôle, cohérent entre les threads de contrôle et magasins. L'intégration de DFD-ERD s'effectue à l'aide d'un objet manquant dans SADT - un magasin de données dont la structure est décrite à l'aide d'ERD et est cohérente avec les flux correspondants et autres magasins sur 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 en s'appuyant sur ses résultats). Les DFD peuvent être facilement convertis en modèles de conception (cartes structurelles) - ce sont des modèles similaires. De plus, un certain nombre d'algorithmes sont connus pour convertir automatiquement la hiérarchie DFD en cartes structurelles de différents types, ce qui garantit une transition logique et indolore de l'étape d'analyse des exigences à la conception du système. D'un autre côté, les méthodes formelles permettant de convertir les diagrammes SADT en solutions de conception de systèmes de contrôle automatisés sont inconnues.

Néanmoins, il convient de noter que les types d'analyse structurelle considérés sont essentiellement deux langages de puissance à peu près égale pour transmettre la compréhension. Et l'un des principaux critères de sélection est le suivant : dans quelle mesure le consultant ou l'analyste parle chacune de ces langues, avec quelle compétence il peut exprimer ses pensées dans cette langue.