logo

Modèle V SDLC – Génie logiciel

Le modèle V est un type de Modèle SDLC où le processus s’exécute séquentiellement en forme de V. Il est également connu sous le nom de modèle de vérification et de validation. Il repose sur l’association d’une phase de tests à chaque étape de développement correspondante. Le développement de chaque étape est directement associé à la phase de test. La phase suivante ne commence qu'après l'achèvement de la phase précédente, c'est-à-dire que pour chaque activité de développement, il existe une activité de test qui lui correspond.

Table des matières



Le V-Model est un modèle de cycle de vie de développement logiciel (SDLC) qui fournit une représentation systématique et visuelle du processus de développement logiciel. Il est basé sur l'idée d'une forme en V, les deux branches du V représentant la progression du processus de développement de logiciels depuis rassemblement des exigences et l'analyse jusqu'à la conception, la mise en œuvre, les tests et la maintenance.

Conception du modèle en V

  1. Collecte et analyse des exigences : La première phase du modèle V est la phase de collecte et d'analyse des exigences, au cours de laquelle les exigences du client concernant le logiciel sont rassemblées et analysées pour déterminer la portée du projet.
  2. Conception: Lors de la phase de conception, l'architecture et la conception du logiciel sont développées, y compris la conception de haut niveau et la conception détaillée.
  3. Mise en œuvre: Lors de la phase de mise en œuvre, le logiciel est construit sur la base de la conception.
  4. Essai: Lors de la phase de test, le logiciel est testé pour garantir qu’il répond aux exigences du client et qu’il est de haute qualité.
  5. Déploiement: Lors de la phase de déploiement, le logiciel est déployé et mis en service.
  6. Entretien: Lors de la phase de maintenance, le logiciel est maintenu pour garantir qu’il continue de répondre aux besoins et aux attentes du client.
  7. Le modèle V est souvent utilisé en toute sécurité : systèmes critiques, tels que les systèmes aérospatiaux et de défense, en raison de l'accent mis sur des tests approfondis et de sa capacité à définir clairement les étapes impliquées dans le processus de développement logiciel.

Modèle SDLC V

L'illustration suivante décrit les différentes phases d'un modèle en V du SDLC.



Vérification Étapes :

Il s’agit d’une technique d’analyse statique (révision) réalisée sans exécuter de code. Il s'agit du processus d'évaluation de la phase de développement d'un produit visant à déterminer si les exigences spécifiées sont respectées.

Il existe plusieurs phases de vérification dans le modèle V :

Analyse des besoins de l'entreprise :



Il s’agit de la première étape de la désignation du cycle de développement où les exigences du produit doivent être traitées du point de vue du client. dans ces phases, incluez une communication appropriée avec le client pour comprendre les exigences des clients. ce sont des activités très importantes qui doivent être gérées correctement, car la plupart du temps, les clients ne savent pas exactement ce qu'ils veulent et n'en sont pas sûrs à ce moment-là. Nous utilisons donc un conception des tests d'acceptation planification qui est effectuée au moment des besoins commerciaux, elle sera utilisée comme saisir pour les tests d'acceptation.

Conception du système :

La conception du système commencera lorsque nous serons globalement clairs avec les exigences du produit, puis nous devrons concevoir complètement le système. Cette compréhension sera au début complète dans le cadre du processus de développement du produit. ceux-ci seront bénéfiques pour l’exécution future des cas de test.

Conception architecturale:

À ce stade, les spécifications architecturales sont comprises et conçues. Habituellement, plusieurs approches techniques sont proposées et le choix final est fait après avoir examiné à la fois la viabilité technique et financière. L'architecture du système est divisée en modules qui gèrent chacun une fonction distincte. Un autre nom pour cela est High-Level Design (HLD).

À ce stade, l'échange de données et la communication entre les modules internes et les systèmes externes sont bien compris et définis. Au cours de cette phase, des tests d'intégration peuvent être créés et documentés à l'aide des informations fournies.

Conception des modules :

Cette phase, connue sous le nom de Low-Level Design (LLD), spécifie la conception interne complète de chaque module système. La compatibilité entre la conception et d'autres systèmes externes ainsi que d'autres modules de l'architecture du système est cruciale. Les tests unitaires sont un élément crucial de tout processus de développement car ils aident à identifier et à éliminer la majorité des erreurs et des défauts à un stade précoce. Sur la base des conceptions de modules internes, ces tests unitaires peuvent désormais être créés.

Phase de codage :

L'étape de codage consiste à écrire le code des modules système créés lors de la phase de conception. Les exigences système et architecturales sont utilisées pour déterminer quel langage de programmation est le plus approprié.

Les normes et principes de codage sont suivis lors de l’exécution du codage. Avant que la version finale ne soit archivée dans le référentiel, le code est soumis à de nombreuses révisions de code et est optimisé pour des performances optimales.

Validation Étapes :

Cela implique des techniques d'analyse dynamique (fonctionnelles et non fonctionnelles) et des tests effectués en exécutant du code. La validation est le processus d'évaluation du logiciel après l'achèvement de la phase de développement pour déterminer si le logiciel répond aux attentes et aux exigences du client.

Ainsi, le modèle V contient des phases de vérification d'un côté et des phases de validation de l'autre côté. Les phases de vérification et de validation sont rejointes par la phase de codage en forme de V. Ainsi, on l’appelle V-Model.
Il y a plusieurs Validation phases dans le modèle V :

boucle de programme Java

Tests unitaires :

Les plans de tests unitaires sont développés pendant la phase de conception du module. Ces plans de tests unitaires sont exécutés pour éliminer les bogues au niveau du code ou de l’unité.

Tests d'intégration :

Une fois les tests unitaires terminés, des tests d’intégration sont effectués. Lors des tests d'intégration, les modules sont intégrés et le système est testé. Les tests d'intégration sont effectués lors de la phase de conception de l'architecture. Ce test vérifie la communication des modules entre eux.

Test du système :

Les tests système testent l’application complète avec ses fonctionnalités, son interdépendance et sa communication. Il teste les exigences fonctionnelles et non fonctionnelles de l’application développée.

Tests d'acceptation des utilisateurs (UAT) :

L'UAT est effectuée dans un environnement utilisateur qui ressemble à l'environnement de production. UAT vérifie que le système livré répond aux exigences de l'utilisateur et que le système est prêt à être utilisé dans le monde réel.

Phase de conception:

  • Analyse des besoins : Cette phase contient une communication détaillée avec le client pour comprendre ses exigences et ses attentes. Cette étape est connue sous le nom de collecte des exigences.
  • Conception du système : Cette phase contient la conception du système et la configuration complète du matériel et de la communication pour le développement du produit.
  • Conception architecturale: La conception du système est décomposée en modules reprenant différentes fonctionnalités. Le transfert de données et la communication entre les modules internes et avec le monde extérieur (autres systèmes) sont clairement compris.
  • Conception des modules : Dans cette phase, le système se décompose en petits modules. La conception détaillée des modules est spécifiée, également connue sous le nom de Low-Level Design (LLD).

Phases de tests :

  • Tests unitaires : Les plans de tests unitaires sont développés pendant la phase de conception du module. Ces plans de tests unitaires sont exécutés pour éliminer les bogues au niveau du code ou de l’unité.
  • Tests d'intégration : Une fois les tests unitaires terminés, des tests d’intégration sont effectués. Lors des tests d'intégration, les modules sont intégrés et le système est testé. Les tests d'intégration sont effectués lors de la phase de conception de l'architecture. Ce test vérifie la communication des modules entre eux.
  • Test du système : Les tests système testent l’application complète avec ses fonctionnalités, son interdépendance et sa communication. Il teste les exigences fonctionnelles et non fonctionnelles de l'application développée.
  • Tests d'acceptation des utilisateurs (UAT) : L'UAT est effectuée dans un environnement utilisateur qui ressemble à l'environnement de production. UAT vérifie que le système livré répond aux exigences de l'utilisateur et que le système est prêt à être utilisé dans le monde réel.

Défi industriel :

À mesure que l'industrie a évolué, les technologies sont devenues plus complexes, de plus en plus rapides et en constante évolution. Cependant, il subsiste un ensemble de principes et de concepts de base qui sont aussi applicables aujourd'hui qu'à l'époque où l'informatique en était à ses balbutiements.

  • Définir et affiner avec précision les besoins des utilisateurs.
  • Concevoir et construire une application selon les exigences des utilisateurs autorisés.
  • Vérifiez que l'application qu'ils ont créée respecte les exigences commerciales autorisées.

Importance du modèle V

1. Identification précoce des défauts

En intégrant des tâches de vérification et de validation à chaque étape du processus de développement, le modèle V encourage les tests précoces. Cela réduit les coûts et les efforts nécessaires pour résoudre les problèmes plus tard dans le cycle de développement en facilitant la détection et la résolution précoces des défauts.

2. déterminer les phases de développement et de test

Le V-Model contient une phase de test qui correspond à chaque étape du processus de développement. En garantissant que les processus de test et de développement sont clairement définis, cette cartographie claire favorise une approche méthodique et ordonnée du génie logiciel.

3. Empêche les tests Big Bang

Les tests sont fréquemment effectués à la toute fin du cycle de vie du développement dans les modèles de développement traditionnels, ce qui aboutit à une approche Big Bang où toutes les opérations de test sont concentrées en même temps. En intégrant les activités de test dans le processus de développement et en encourageant une approche de test plus progressive et réglementée, le modèle V évite cela.

4. Améliore la coopération

À tous les niveaux, le V-Model favorise la coopération entre les équipes de test et de développement. Grâce à cette collaboration, les exigences du projet, les choix de conception et les méthodologies de test sont mieux compris, ce qui améliore l'efficacité et l'efficience du processus de développement.

5. Assurance qualité améliorée

L'assurance qualité globale est renforcée par le modèle V, qui intègre des opérations de test à tous les niveaux. Avant que le programme n'atteigne la phase finale de déploiement, il s'assure qu'il répond aux exigences et passe par un processus strict de validation et de vérification.

Principes du modèle V

  • Grand à petit : Dans V-Model, les tests sont effectués dans une perspective hiérarchique, par exemple, les exigences identifiées par l'équipe de projet, la création des phases de conception de haut niveau et de conception détaillée du projet. Au fur et à mesure que chacune de ces phases est complétée, les exigences qu'elles définissent deviennent de plus en plus raffinées et détaillées.
  • Intégrité des données/processus : Ce principe stipule que la conception réussie de tout projet nécessite l'incorporation et la cohésion des données et des processus. Les éléments du processus doivent être identifiés à chaque exigence.
  • Évolutivité : Ce principe stipule que le concept V-Model a la flexibilité nécessaire pour s'adapter à tout projet informatique, quelle que soit sa taille, sa complexité ou sa durée.
  • Références croisées : Une corrélation directe entre les exigences et l’activité de test correspondante est connue sous le nom de références croisées.

Documentation tangible :

Ce principe stipule que chaque projet doit créer un document. Cette documentation est requise et appliquée à la fois par l’équipe de développement du projet et par l’équipe de support. La documentation est utilisée pour maintenir l'application une fois qu'elle est disponible dans un environnement de production.

Pourquoi préféré ?

  • Il est facile à gérer grâce à la rigidité du modèle. Chaque phase du V-Model comporte des livrables spécifiques et un processus de révision.
  • Suivi proactif des défauts : les défauts sont détectés à un stade précoce.

Quand utiliser de Modèle V ?

  • Traçabilité des Exigences : Le modèle V s’avère bénéfique dans les situations où il est impératif de créer une traçabilité précise entre les exigences et les cas de test associés.
  • Projets complexes : Le V-Model offre un moyen méthodique de gérer les activités de test et de réduire les risques liés aux problèmes d'intégration et d'interface pour les projets présentant un niveau élevé de complexité et d'interdépendances entre les composants du système.
  • Projets de type cascade : Étant donné que le modèle V offre une structure accessible pour organiser, réaliser et surveiller les activités de test à chaque niveau de développement, il convient aux projets qui utilisent une approche séquentielle de développement, un peu comme le modèle en cascade.
  • Systèmes critiques pour la sécurité : Ces systèmes sont utilisés dans les secteurs de l'aérospatiale, de l'automobile et de la santé. Ils mettent fortement l'accent sur des procédures rigides de vérification et de validation, qui contribuent à garantir que les exigences essentielles du système sont remplies et que les risques potentiels sont détectés et éliminés dès le début du processus de développement.

Avantages du modèle V

  • Il s'agit d'un modèle très discipliné et les phases sont complétées une par une.
  • V-Model est utilisé pour les petits projets où les exigences du projet sont claires.
  • Simple et facile à comprendre et à utiliser.
  • Ce modèle se concentre sur les activités de vérification et de validation au début du cycle de vie, augmentant ainsi la probabilité de créer un produit sans erreur et de bonne qualité.
  • Il permet à la gestion de projet de suivre les progrès avec précision.
  • Processus clair et structuré : Le modèle en V fournit un processus clair et structuré pour développement de logiciels , ce qui le rend plus facile à comprendre et à suivre.
  • Accent mis sur les tests : le modèle V met fortement l'accent sur les tests, ce qui contribue à garantir la qualité et la fiabilité du logiciel.
  • Traçabilité améliorée : le modèle en V fournit un lien clair entre les exigences et le produit final, facilitant ainsi le suivi et la gestion des modifications apportées au logiciel.
  • Meilleure communication : la structure claire du modèle V contribue à améliorer la communication entre le client et l'équipe de développement.

Inconvénients du modèle V

  • Risque et incertitude élevés.
  • Ce n'est pas bon pour les projets complexes et orientés objet.
  • Il ne convient pas aux projets dont les exigences ne sont pas claires et comportent un risque élevé de changement.
  • Ce modèle ne prend pas en charge l'itération des phases.
  • Il ne gère pas facilement les événements simultanés.
  • Inflexibilité : le modèle en V est un modèle linéaire et séquentiel, ce qui peut rendre difficile l'adaptation à des exigences changeantes ou à des événements inattendus.
  • Prendre du temps : le modèle V peut prendre beaucoup de temps, car il nécessite beaucoup de documentation et de tests.
  • Dépendance excessive à l'égard de la documentation : le modèle en V met fortement l'accent sur la documentation, ce qui peut conduire à une dépendance excessive à l'égard de la documentation au détriment du travail de développement réel.

Conclusion

Une approche scientifique et organisée du cycle de vie du développement logiciel (SDLC) est fournie par le modèle en V du génie logiciel. L'expertise de l'équipe avec la méthodologie sélectionnée, les caractéristiques uniques du projet et la nature des exigences doivent tous être pris en considération lors de la sélection des modèles SDLC, y compris le modèle V.

Livre de référence:

Génie logiciel : approche d'un praticien par Roger S. Pressman, publié par McGraw-Hill Education, 2017.