SDLC - Modèle V

Le modèle V est un modèle SDLC où l'exécution des processus se produit de manière séquentielle en forme de V. Il est également connu sous le nom deVerification and Validation model.

Le V-Model est une extension du modèle en cascade et repose sur l'association d'une phase de test pour chaque étape de développement correspondante. Cela signifie que pour chaque phase du cycle de développement, il y a une phase de test directement associée. Il s'agit d'un modèle hautement discipliné et la phase suivante ne commence qu'après l'achèvement de la phase précédente.

Modèle en V - Conception

Dans le cadre du V-Model, la phase de test correspondante de la phase de développement est planifiée en parallèle. Ainsi, il y a des phases de vérification d'un côté des phases «V» et de validation de l'autre côté. La phase de codage relie les deux côtés du modèle en V.

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

Modèle en V - Phases de vérification

Il existe plusieurs phases de vérification dans le modèle en V, chacune d'entre elles étant expliquée en détail ci-dessous.

Analyse des besoins commerciaux

Il s'agit de la première phase du cycle de développement où les exigences du produit sont comprises du point de vue du client. Cette phase implique une communication détaillée avec le client pour comprendre ses attentes et ses besoins précis. Il s'agit d'une activité très importante qui doit être bien gérée, car la plupart des clients ne sont pas sûrs de ce dont ils ont exactement besoin. leacceptance test design planning est effectué à ce stade car les exigences de l'entreprise peuvent être utilisées comme entrée pour les tests d'acceptation.

Conception du système

Une fois que vous avez les exigences produit claires et détaillées, il est temps de concevoir le système complet. La conception du système comprendra et détaillera la configuration matérielle et de communication complète du produit en cours de développement. Le plan de test du système est développé en fonction de la conception du système. Faire cela à un stade plus précoce laisse plus de temps pour l'exécution réelle du test plus tard.

Conception architecturale

Les spécifications architecturales sont comprises et conçues dans cette phase. Habituellement, plus d'une approche technique est proposée et en fonction de la faisabilité technique et financière, la décision finale est prise. La conception du système est subdivisée en modules prenant différentes fonctionnalités. Ceci est également appeléHigh Level Design (HLD).

Le transfert de données et la communication entre les modules internes et avec le monde extérieur (autres systèmes) sont clairement compris et définis à cette étape. Avec ces informations, des tests d'intégration peuvent être conçus et documentés au cours de cette étape.

Conception du module

Au cours de cette phase, la conception interne détaillée de tous les modules du système est spécifiée, appelée Low Level Design (LLD). Il est important que la conception soit compatible avec les autres modules de l'architecture du système et les autres systèmes externes. Les tests unitaires sont une partie essentielle de tout processus de développement et aident à éliminer le maximum de défauts et d'erreurs à un stade très précoce. Ces tests unitaires peuvent être conçus à ce stade sur la base des conceptions des modules internes.

Phase de codage

Le codage proprement dit des modules système conçus dans la phase de conception est repris dans la phase de codage. Le langage de programmation le mieux adapté est choisi en fonction des exigences du système et de l'architecture.

Le codage est effectué sur la base des directives et des normes de codage. Le code passe par de nombreuses révisions de code et est optimisé pour de meilleures performances avant que la version finale ne soit archivée dans le référentiel.

Phases de validation

Les différentes phases de validation dans un modèle en V sont expliquées en détail ci-dessous.

Test unitaire

Les tests unitaires conçus dans la phase de conception du module sont exécutés sur le code lors de cette phase de validation. Les tests unitaires sont les tests au niveau du code et aident à éliminer les bogues à un stade précoce, bien que tous les défauts ne puissent pas être découverts par les tests unitaires.

Test d'intégration

Les tests d'intégration sont associés à la phase de conception architecturale. Des tests d'intégration sont effectués pour tester la coexistence et la communication des modules internes au système.

Test du système

Le test du système est directement associé à la phase de conception du système. Les tests système vérifient l'ensemble des fonctionnalités du système et la communication du système en cours de développement avec les systèmes externes. La plupart des problèmes de compatibilité logicielle et matérielle peuvent être découverts lors de l'exécution de ce test système.

Test d'acceptation

Les tests d'acceptation sont associés à la phase d'analyse des besoins métier et impliquent de tester le produit dans l'environnement utilisateur. Les tests d'acceptation révèlent les problèmes de compatibilité avec les autres systèmes disponibles dans l'environnement utilisateur. Il découvre également les problèmes non fonctionnels tels que les défauts de charge et de performance dans l'environnement utilisateur réel.

V- Modèle ─ Application

L'application V-Model est presque la même que le modèle en cascade, car les deux modèles sont de type séquentiel. Les exigences doivent être très claires avant le démarrage du projet, car il est généralement coûteux de revenir en arrière et d'apporter des modifications. Ce modèle est utilisé dans le domaine du développement médical, car il s'agit d'un domaine strictement discipliné.

Les pointeurs suivants sont quelques-uns des scénarios les plus appropriés pour utiliser l'application V-Model.

  • Les exigences sont bien définies, clairement documentées et fixées.

  • La définition du produit est stable.

  • La technologie n'est pas dynamique et est bien comprise par l'équipe du projet.

  • Il n'y a pas d'exigences ambiguës ou indéfinies.

  • Le projet est court.

Modèle en V - Avantages et inconvénients

L'avantage de la méthode V-Model est qu'elle est très facile à comprendre et à appliquer. La simplicité de ce modèle facilite également sa gestion. L'inconvénient est que le modèle n'est pas flexible aux changements et juste au cas où il y aurait un changement d'exigence, ce qui est très courant dans le monde dynamique d'aujourd'hui, il devient très coûteux de faire le changement.

Les avantages de la méthode V-Model sont les suivants -

  • Il s'agit d'un modèle hautement discipliné et les phases sont effectuées une par une.

  • Fonctionne bien pour les petits projets où les exigences sont très bien comprises.

  • Simple et facile à comprendre et à utiliser.

  • Facile à gérer grâce à la rigidité du modèle. Chaque phase a des livrables spécifiques et un processus d'examen.

Les inconvénients de la méthode V-Model sont les suivants -

  • Risque élevé et incertitude.

  • Pas un bon modèle pour les projets complexes et orientés objet.

  • Mauvais modèle pour les projets longs et en cours.

  • Ne convient pas aux projets où les exigences présentent un risque modéré à élevé de changement.

  • Une fois qu'une application est en phase de test, il est difficile de revenir en arrière et de modifier une fonctionnalité.

  • Aucun logiciel fonctionnel n'est produit jusqu'à la fin du cycle de vie.