SDLC - Guide rapide

Le cycle de vie du développement logiciel (SDLC) est un processus utilisé par l'industrie du logiciel pour concevoir, développer et tester des logiciels de haute qualité. Le SDLC vise à produire un logiciel de haute qualité qui répond ou dépasse les attentes des clients, arrive à terme dans les délais et les estimations de coûts.

  • SDLC est l'acronyme de Software Development Life Cycle.

  • Il est également appelé processus de développement logiciel.

  • SDLC est un cadre définissant les tâches exécutées à chaque étape du processus de développement logiciel.

  • ISO / CEI 12207 est une norme internationale pour les processus du cycle de vie des logiciels. Il vise à être la norme qui définit toutes les tâches requises pour le développement et la maintenance des logiciels.

Qu'est-ce que le SDLC?

SDLC est un processus suivi pour un projet logiciel, au sein d'une organisation logicielle. Il consiste en un plan détaillé décrivant comment développer, maintenir, remplacer et modifier ou améliorer un logiciel spécifique. Le cycle de vie définit une méthodologie pour améliorer la qualité des logiciels et le processus de développement global.

La figure suivante est une représentation graphique des différentes étapes d'un SDLC typique.

Un cycle de vie de développement logiciel typique comprend les étapes suivantes:

Étape 1: Planification et analyse des besoins

L'analyse des exigences est l'étape la plus importante et la plus fondamentale du SDLC. Il est réalisé par les membres seniors de l'équipe avec les contributions du client, du service commercial, des études de marché et des experts du domaine de l'industrie. Ces informations sont ensuite utilisées pour planifier l'approche de base du projet et pour mener une étude de faisabilité du produit dans les domaines économique, opérationnel et technique.

La planification des exigences d'assurance qualité et l'identification des risques associés au projet sont également effectuées au stade de la planification. Le résultat de l'étude de faisabilité technique est de définir les différentes approches techniques qui peuvent être suivies pour mettre en œuvre le projet avec succès avec un minimum de risques.

Étape 2: Définition des exigences

Une fois l'analyse des exigences effectuée, l'étape suivante consiste à définir et à documenter clairement les exigences du produit et à les faire approuver par le client ou les analystes du marché. Cela se fait par unSRS (Software Requirement Specification) document qui comprend toutes les exigences du produit à concevoir et à développer pendant le cycle de vie du projet.

Étape 3: Conception de l'architecture du produit

SRS est la référence des architectes de produits pour proposer la meilleure architecture pour le produit à développer. Sur la base des exigences spécifiées dans le SRS, plus d'une approche de conception pour l'architecture du produit est généralement proposée et documentée dans un DDS - Design Document Specification.

Cette DDS est revue par toutes les parties prenantes importantes et basée sur divers paramètres tels que l'évaluation des risques, la robustesse du produit, la modularité de la conception, les contraintes de budget et de temps, la meilleure approche de conception est sélectionnée pour le produit.

Une approche de conception définit clairement tous les modules architecturaux du produit ainsi que sa communication et sa représentation des flux de données avec les modules externes et tiers (le cas échéant). La conception interne de tous les modules de l'architecture proposée doit être clairement définie avec les moindres détails dans DDS.

Étape 4: Construction ou développement du produit

À cette étape du SDLC, le développement proprement dit commence et le produit est construit. Le code de programmation est généré selon DDS au cours de cette étape. Si la conception est effectuée de manière détaillée et organisée, la génération de code peut être effectuée sans trop de tracas.

Les développeurs doivent suivre les directives de codage définies par leur organisation et des outils de programmation tels que des compilateurs, des interprètes, des débogueurs, etc. sont utilisés pour générer le code. Différents langages de programmation de haut niveau tels que C, C ++, Pascal, Java et PHP sont utilisés pour le codage. Le langage de programmation est choisi en fonction du type de logiciel en cours de développement.

Étape 5: Test du produit

Cette étape est généralement un sous-ensemble de toutes les étapes car dans les modèles SDLC modernes, les activités de test sont principalement impliquées dans toutes les étapes de SDLC. Cependant, cette étape fait référence à l'étape de test uniquement du produit où les défauts du produit sont signalés, suivis, corrigés et retestés, jusqu'à ce que le produit atteigne les normes de qualité définies dans le SRS.

Étape 6: Déploiement sur le marché et maintenance

Une fois que le produit est testé et prêt à être déployé, il est officiellement commercialisé sur le marché approprié. Parfois, le déploiement du produit se fait par étapes, conformément à la stratégie commerciale de cette organisation. Le produit peut d'abord être commercialisé dans un segment limité et testé dans l'environnement commercial réel (test d'acceptation UAT-User).

Ensuite, en fonction des commentaires, le produit peut être publié tel quel ou avec des améliorations suggérées dans le segment de marché du ciblage. Une fois le produit mis sur le marché, sa maintenance est effectuée pour la clientèle existante.

Modèles SDLC

Il existe différents modèles de cycle de vie de développement logiciel définis et conçus qui sont suivis pendant le processus de développement logiciel. Ces modèles sont également appelés modèles de processus de développement logiciel ". Chaque modèle de processus suit une série d'étapes uniques à son type pour assurer le succès du processus de développement logiciel.

Voici les modèles SDLC les plus importants et les plus populaires suivis dans l'industrie -

  • Modèle de cascade
  • Modèle itératif
  • Modèle en spirale
  • V-Model
  • Modèle Big Bang

D'autres méthodologies associées sont le modèle agile, le modèle RAD, le développement rapide d'applications et les modèles de prototypage.

Le modèle de cascade a été le premier modèle de processus à être introduit. Il est également appelé unlinear-sequential life cycle model. Il est très simple à comprendre et à utiliser. Dans un modèle en cascade, chaque phase doit être terminée avant que la phase suivante puisse commencer et il n'y a pas de chevauchement dans les phases.

Le modèle Waterfall est la première approche SDLC utilisée pour le développement de logiciels.

Le modèle en cascade illustre le processus de développement logiciel dans un flux séquentiel linéaire. Cela signifie que toute phase du processus de développement ne commence que si la phase précédente est terminée. Dans ce modèle en cascade, les phases ne se chevauchent pas.

Modèle de cascade - Conception

L'approche en cascade a été le premier modèle SDLC à être largement utilisé en génie logiciel pour assurer le succès du projet. Dans l'approche «The Waterfall», l'ensemble du processus de développement logiciel est divisé en phases distinctes. Dans ce modèle en cascade, en général, le résultat d'une phase agit en tant qu'entrée pour la phase suivante de manière séquentielle.

L'illustration suivante est une représentation des différentes phases du modèle de cascade.

Les phases séquentielles du modèle Waterfall sont:

  • Requirement Gathering and analysis - Toutes les exigences possibles du système à développer sont capturées dans cette phase et documentées dans un document de spécification des exigences.

  • System Design- Les spécifications des exigences de la première phase sont étudiées dans cette phase et la conception du système est préparée. Cette conception de système aide à spécifier les exigences matérielles et système et aide à définir l'architecture globale du système.

  • Implementation- Avec les entrées de la conception du système, le système est d'abord développé dans de petits programmes appelés unités, qui sont intégrés dans la phase suivante. Chaque unité est développée et testée pour sa fonctionnalité, appelée test unitaire.

  • Integration and Testing- Toutes les unités développées dans la phase de mise en œuvre sont intégrées dans un système après le test de chaque unité. Après l'intégration, l'ensemble du système est testé pour détecter d'éventuels défauts et pannes.

  • Deployment of system- Une fois les tests fonctionnels et non fonctionnels effectués; le produit est déployé dans l'environnement client ou mis sur le marché.

  • Maintenance- Certains problèmes surviennent dans l'environnement client. Pour résoudre ces problèmes, des correctifs sont publiés. Aussi pour améliorer le produit, de meilleures versions sont publiées. La maintenance est effectuée pour fournir ces changements dans l'environnement client.

Toutes ces phases sont en cascade les unes aux autres dans lesquelles le progrès est considéré comme coulant régulièrement vers le bas (comme une cascade) à travers les phases. La phase suivante est lancée seulement après que l'ensemble défini d'objectifs a été atteint pour la phase précédente et elle est validée, donc le nom "Waterfall Model". Dans ce modèle, les phases ne se chevauchent pas.

Modèle de cascade - Application

Chaque logiciel développé est différent et nécessite une approche SDLC appropriée à suivre en fonction des facteurs internes et externes. Certaines situations où l'utilisation du modèle Waterfall est la plus appropriée sont:

  • Les exigences sont très bien documentées, claires et fixes.

  • La définition du produit est stable.

  • La technologie est comprise et n'est pas dynamique.

  • Il n'y a pas d'exigences ambiguës.

  • De nombreuses ressources avec l'expertise requise sont disponibles pour soutenir le produit.

  • Le projet est court.

Modèle de cascade - Avantages

Les avantages du développement en cascade sont qu'il permet une départementalisation et un contrôle. Un calendrier peut être établi avec des dates limites pour chaque étape de développement et un produit peut passer par les phases du modèle de processus de développement une par une.

Le développement passe du concept à la conception, à la mise en œuvre, aux tests, à l'installation, au dépannage et se termine par l'exploitation et la maintenance. Chaque phase de développement se déroule dans un ordre strict.

Certains des principaux avantages du modèle de cascade sont les suivants:

  • 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 phases sont traitées et terminées une par une.

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

  • Des étapes clairement définies.

  • Jalons bien compris.

  • Facile à organiser les tâches.

  • Le processus et les résultats sont bien documentés.

Modèle de cascade - Inconvénients

L'inconvénient du développement en cascade est qu'il ne permet pas beaucoup de réflexion ou de révision. Une fois qu'une application est en phase de test, il est très difficile de revenir en arrière et de changer quelque chose qui n'a pas été bien documenté ou réfléchi à l'étape du concept.

Les principaux inconvénients du modèle en cascade sont les suivants:

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

  • Risque et incertitude élevés.

  • 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. Ainsi, le risque et l'incertitude sont élevés avec ce modèle de processus.

  • Il est difficile de mesurer les progrès par étapes.

  • Ne peut pas répondre aux exigences changeantes.

  • Ajuster la portée pendant le cycle de vie peut mettre fin à un projet.

  • L'intégration se fait comme un «big-bang» à la toute fin, ce qui ne permet pas d'identifier tôt les goulots d'étranglement ou les défis technologiques ou commerciaux.

Dans le modèle itératif, le processus itératif commence par une implémentation simple d'un petit ensemble d'exigences logicielles et améliore de manière itérative les versions en évolution jusqu'à ce que le système complet soit implémenté et prêt à être déployé.

Un modèle de cycle de vie itératif ne tente pas de commencer par une spécification complète des exigences. Au lieu de cela, le développement commence par la spécification et la mise en œuvre d'une partie seulement du logiciel, qui est ensuite revue pour identifier d'autres exigences. Ce processus est ensuite répété, produisant une nouvelle version du logiciel à la fin de chaque itération du modèle.

Modèle itératif - Conception

Le processus itératif commence par une implémentation simple d'un sous-ensemble des exigences logicielles et améliore de manière itérative les versions en évolution jusqu'à ce que le système complet soit implémenté. À chaque itération, des modifications de conception sont apportées et de nouvelles capacités fonctionnelles sont ajoutées. L'idée de base derrière cette méthode est de développer un système à travers des cycles répétés (itératifs) et par petites portions à la fois (incrémentales).

L'illustration suivante est une représentation du modèle itératif et incrémental -

Le développement itératif et incrémental est une combinaison de conception itérative ou de méthode itérative et de modèle de construction incrémentielle pour le développement. "Pendant le développement logiciel, plusieurs itérations du cycle de développement logiciel peuvent être en cours en même temps." Ce processus peut être décrit comme une «approche d'acquisition évolutive» ou de «construction incrémentielle» ».

Dans ce modèle incrémentiel, l'ensemble des exigences est divisé en différentes versions. Au cours de chaque itération, le module de développement passe par les phases d'exigences, de conception, de mise en œuvre et de test. Chaque version ultérieure du module ajoute une fonction à la version précédente. Le processus se poursuit jusqu'à ce que le système complet soit prêt selon l'exigence.

La clé d'une utilisation réussie d'un cycle de vie de développement logiciel itératif est une validation rigoureuse des exigences, ainsi que la vérification et le test de chaque version du logiciel par rapport à ces exigences dans chaque cycle du modèle. Au fur et à mesure que le logiciel évolue au fil des cycles successifs, les tests doivent être répétés et étendus pour vérifier chaque version du logiciel.

Modèle itératif - Application

Comme d'autres modèles SDLC, le développement itératif et incrémental a des applications spécifiques dans l'industrie du logiciel. Ce modèle est le plus souvent utilisé dans les scénarios suivants -

  • Les exigences du système complet sont clairement définies et comprises.

  • Les exigences majeures doivent être définies; cependant, certaines fonctionnalités ou améliorations demandées peuvent évoluer avec le temps.

  • Il y a un temps à la contrainte du marché.

  • Une nouvelle technologie est utilisée et apprise par l'équipe de développement tout en travaillant sur le projet.

  • Les ressources avec les compétences nécessaires ne sont pas disponibles et sont prévues pour être utilisées sous contrat pour des itérations spécifiques.

  • Certaines caractéristiques et objectifs à haut risque peuvent changer à l'avenir.

Modèle itératif - Avantages et inconvénients

L'avantage de ce modèle est qu'il existe un modèle fonctionnel du système à un stade très précoce de développement, ce qui facilite la recherche de défauts fonctionnels ou de conception. La détection des problèmes à un stade précoce du développement permet de prendre des mesures correctives dans un budget limité.

L'inconvénient de ce modèle SDLC est qu'il ne s'applique qu'aux projets de développement logiciel volumineux et volumineux. En effet, il est difficile de diviser un petit système logiciel en de petits incréments / modules réparables supplémentaires.

Les avantages du modèle SDLC itératif et incrémental sont les suivants:

  • Certaines fonctionnalités de travail peuvent être développées rapidement et tôt dans le cycle de vie.

  • Les résultats sont obtenus tôt et périodiquement.

  • Un développement parallèle peut être planifié.

  • Les progrès peuvent être mesurés.

  • Moins coûteux pour modifier la portée / les exigences.

  • Les tests et le débogage au cours d'une itération plus petite sont faciles.

  • Les risques sont identifiés et résolus lors de l'itération; et chaque itération est un jalon facile à gérer.

  • Gestion des risques plus facile - La partie à haut risque est effectuée en premier.

  • À chaque incrément, le produit opérationnel est livré.

  • Les problèmes, défis et risques identifiés à partir de chaque incrément peuvent être utilisés / appliqués à l'incrément suivant.

  • L'analyse des risques est meilleure.

  • Il prend en charge l'évolution des exigences.

  • Le temps de fonctionnement initial est inférieur.

  • Mieux adapté aux projets de grande envergure et critiques.

  • Au cours du cycle de vie, le logiciel est produit tôt, ce qui facilite l'évaluation et la rétroaction des clients.

Les inconvénients du modèle SDLC itératif et incrémental sont les suivants:

  • Plus de ressources peuvent être nécessaires.

  • Bien que le coût du changement soit moindre, mais il n'est pas très adapté à l'évolution des besoins.

  • Une plus grande attention de la direction est requise.

  • Des problèmes d'architecture ou de conception du système peuvent survenir car toutes les exigences ne sont pas rassemblées au début de tout le cycle de vie.

  • La définition des incréments peut nécessiter la définition du système complet.

  • Ne convient pas aux petits projets.

  • La complexité de gestion est plus.

  • La fin du projet peut ne pas être connue, ce qui constitue un risque.

  • Des ressources hautement qualifiées sont nécessaires pour l'analyse des risques.

  • L'avancement des projets dépend fortement de la phase d'analyse des risques.

Le modèle en spirale combine l'idée de développement itératif avec les aspects systématiques et contrôlés du modèle en cascade. Ce modèle en spirale est une combinaison de modèle de processus de développement itératif et de modèle de développement linéaire séquentiel, c'est-à-dire le modèle en cascade avec un très fort accent sur l'analyse des risques. Il permet des versions incrémentielles du produit ou un raffinement incrémentiel à chaque itération autour de la spirale.

Modèle en spirale - Conception

Le modèle en spirale comporte quatre phases. Un projet logiciel passe à plusieurs reprises par ces phases dans des itérations appelées Spirales.

Identification

Cette phase commence par la collecte des exigences métier dans la spirale de référence. Dans les spirales suivantes, au fur et à mesure que le produit mûrit, l'identification des exigences du système, des exigences du sous-système et des exigences de l'unité sont toutes effectuées dans cette phase.

Cette phase comprend également la compréhension des exigences du système par une communication continue entre le client et l'analyste système. Au bout de la spirale, le produit est déployé sur le marché identifié.

Conception

La phase de conception commence par la conception conceptuelle dans la spirale de base et implique la conception architecturale, la conception logique des modules, la conception physique du produit et la conception finale dans les spirales suivantes.

Construire ou construire

La phase de construction fait référence à la production du produit logiciel réel à chaque spirale. Dans la spirale de base, lorsque le produit est juste pensé et que la conception est en cours de développement, un POC (Proof of Concept) est développé dans cette phase pour obtenir les commentaires des clients.

Ensuite, dans les spirales suivantes, avec une plus grande clarté sur les exigences et les détails de conception, un modèle de travail du logiciel appelé build est produit avec un numéro de version. Ces versions sont envoyées au client pour commentaires.

Évaluation et analyse des risques

L'analyse des risques comprend l'identification, l'estimation et le suivi de la faisabilité technique et des risques de gestion, tels que le retard de calendrier et le dépassement des coûts. Après avoir testé la construction, à la fin de la première itération, le client évalue le logiciel et fournit des commentaires.

L'illustration suivante est une représentation du modèle en spirale, répertoriant les activités de chaque phase.

Sur la base de l'évaluation du client, le processus de développement logiciel entre dans l'itération suivante et suit ensuite l'approche linéaire pour mettre en œuvre les commentaires suggérés par le client. Le processus d'itérations le long de la spirale se poursuit tout au long de la vie du logiciel.

Application de modèle en spirale

Le modèle en spirale est largement utilisé dans l'industrie du logiciel car il est synchronisé avec le processus de développement naturel de tout produit, c'est-à-dire l'apprentissage avec maturité qui implique un risque minimum pour le client ainsi que pour les entreprises de développement.

Les pointeurs suivants expliquent les utilisations typiques d'un modèle en spirale -

  • Lorsqu'il y a une contrainte budgétaire et qu'une évaluation des risques est importante.

  • Pour les projets à risque moyen à élevé.

  • Engagement de projet à long terme en raison des changements potentiels des priorités économiques à mesure que les exigences changent avec le temps.

  • Le client n'est pas sûr de ses exigences, ce qui est généralement le cas.

  • Les exigences sont complexes et nécessitent une évaluation pour être clarifiées.

  • Nouvelle gamme de produits qui devrait être lancée par étapes pour obtenir suffisamment de commentaires des clients.

  • Des changements importants sont attendus dans le produit au cours du cycle de développement.

Modèle en spirale - Avantages et inconvénients

L'avantage du modèle de cycle de vie en spirale est qu'il permet d'ajouter des éléments du produit lorsqu'ils deviennent disponibles ou connus. Cela garantit qu'il n'y a pas de conflit avec les exigences et la conception précédentes.

Cette méthode est cohérente avec les approches qui comportent plusieurs versions et versions logicielles, ce qui permet d'effectuer une transition ordonnée vers une activité de maintenance. Un autre aspect positif de cette méthode est que le modèle en spirale oblige un utilisateur précoce à s'impliquer dans l'effort de développement du système.

D'un autre côté, il faut une gestion très stricte pour terminer de tels produits et il y a un risque de faire tourner la spirale dans une boucle indéfinie. Ainsi, la discipline du changement et l'étendue des demandes de changement sont très importantes pour développer et déployer le produit avec succès.

Les avantages du modèle Spiral SDLC sont les suivants:

  • Des exigences changeantes peuvent être adaptées.

  • Permet une utilisation intensive des prototypes.

  • Les exigences peuvent être capturées plus précisément.

  • Les utilisateurs voient le système tôt.

  • Le développement peut être divisé en parties plus petites et les parties à risque peuvent être développées plus tôt, ce qui contribue à une meilleure gestion des risques.

Les inconvénients du modèle Spiral SDLC sont les suivants:

  • La gestion est plus complexe.

  • La fin du projet peut ne pas être connue à l'avance.

  • Ne convient pas aux projets à faible risque ou à faible risque et pourrait être coûteux pour les petits projets.

  • Le processus est complexe

  • La spirale peut durer indéfiniment.

  • Un grand nombre d'étapes intermédiaires nécessite une documentation excessive.

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.

Le modèle Big Bang est un modèle SDLC où nous ne suivons aucun processus spécifique. Le développement commence juste avec l'argent et les efforts requis comme entrée, et la sortie est le logiciel développé qui peut ou non être selon les besoins du client. Ce modèle Big Bang ne suit pas de processus / procédure et il y a très peu de planification requise. Même le client n'est pas sûr de ce qu'il veut exactement et les exigences sont mises en œuvre à la volée sans grande analyse.

Habituellement, ce modèle est suivi pour les petits projets où les équipes de développement sont très petites.

Modèle Big Bang ─ Conception et application

Le modèle Big Bang consiste à concentrer toutes les ressources possibles dans le développement et le codage de logiciels, avec très peu ou pas de planification. Les exigences sont comprises et mises en œuvre au fur et à mesure. Toute modification requise peut nécessiter ou non de réorganiser le logiciel complet.

Ce modèle est idéal pour les petits projets avec un ou deux développeurs travaillant ensemble et est également utile pour les projets académiques ou pratiques. C'est un modèle idéal pour le produit où les exigences ne sont pas bien comprises et la date de sortie finale n'est pas donnée.

Modèle Big Bang - Avantages et inconvénients

L'avantage de ce modèle Big Bang est qu'il est très simple et nécessite très peu ou pas de planification. Facile à gérer et aucune procédure formelle n'est requise.

Cependant, le modèle Big Bang est un modèle à très haut risque et des changements dans les exigences ou des exigences mal comprises peuvent même conduire à un renversement complet ou à un raclage du projet. Il est idéal pour les projets répétitifs ou petits avec un minimum de risques.

Les avantages du modèle Big Bang sont les suivants -

  • Ceci est un modèle très simple

  • Peu ou pas de planification requise

  • Facile à gérer

  • Très peu de ressources requises

  • Donne de la flexibilité aux développeurs

  • C'est une bonne aide à l'apprentissage pour les nouveaux arrivants ou les étudiants.

Les inconvénients du modèle Big Bang sont les suivants -

  • Risque et incertitude très élevés.

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

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

  • Peut s'avérer très coûteux si les exigences sont mal comprises.

Le modèle Agile SDLC est une combinaison de modèles de processus itératifs et incrémentaux mettant l'accent sur l'adaptabilité des processus et la satisfaction du client grâce à la livraison rapide d'un logiciel fonctionnel. Les méthodes agiles divisent le produit en petites versions incrémentielles. Ces builds sont fournis par itérations. Chaque itération dure généralement d'environ une à trois semaines. Chaque itération implique des équipes interfonctionnelles travaillant simultanément sur divers domaines tels que -

  • Planning
  • Analyse des besoins
  • Design
  • Coding
  • Tests unitaires et
  • Test d'acceptation.

À la fin de l'itération, un produit fonctionnel est présenté au client et aux parties prenantes importantes.

Qu'est-ce que Agile?

Le modèle Agile estime que chaque projet doit être traité différemment et que les méthodes existantes doivent être adaptées pour mieux répondre aux exigences du projet. Dans Agile, les tâches sont divisées en boîtes de temps (petits délais) pour fournir des fonctionnalités spécifiques pour une version.

Une approche itérative est adoptée et la construction de logiciels fonctionnels est livrée après chaque itération. Chaque build est incrémental en termes de fonctionnalités; la version finale contient toutes les fonctionnalités requises par le client.

Voici une illustration graphique du modèle Agile -

Le processus de réflexion Agile avait commencé tôt dans le développement du logiciel et a commencé à devenir populaire avec le temps en raison de sa flexibilité et de son adaptabilité.

Les méthodes Agile les plus populaires incluent Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development et Dynamic Systems Development Method (DSDM) (1995). Ceux-ci sont maintenant collectivement appelésAgile Methodologies, après la publication du Manifeste Agile en 2001.

Voici les principes du Manifeste Agile -

  • Individuals and interactions - Dans le développement Agile, l'auto-organisation et la motivation sont importantes, tout comme les interactions comme la colocation et la programmation en binôme.

  • Working software - Un logiciel de démonstration est considéré comme le meilleur moyen de communication avec les clients pour comprendre leurs besoins, au lieu de simplement dépendre de la documentation.

  • Customer collaboration - Étant donné que les exigences ne peuvent pas être rassemblées complètement au début du projet en raison de divers facteurs, une interaction continue avec le client est très importante pour obtenir les exigences du produit appropriées.

  • Responding to change - Le développement Agile est axé sur des réponses rapides au changement et un développement continu.

Modèles SDLC Agile vs traditionnels

Agile est basé sur la adaptive software development methods, alors que les modèles SDLC traditionnels comme le modèle en cascade sont basés sur une approche prédictive. Les équipes prédictives des modèles SDLC traditionnels travaillent généralement avec une planification détaillée et disposent d'une prévision complète des tâches et fonctionnalités exactes à livrer dans les prochains mois ou au cours du cycle de vie du produit.

Les méthodes prédictives dépendent entièrement de la requirement analysis and planningfait au début du cycle. Tous les changements à intégrer passent par une gestion et une hiérarchisation strictes du contrôle des changements.

Agile utilise un adaptive approachoù il n'y a pas de planification détaillée et il n'y a de clarté sur les tâches futures qu'en ce qui concerne les fonctionnalités à développer. Il y a un développement axé sur les fonctionnalités et l'équipe s'adapte de manière dynamique aux exigences changeantes du produit. Le produit est testé très fréquemment, à travers les itérations de version, minimisant le risque d'éventuelles pannes majeures à l'avenir.

Customer Interactionest l'épine dorsale de cette méthodologie Agile, et une communication ouverte avec une documentation minimale sont les caractéristiques typiques de l'environnement de développement Agile. Les équipes agiles travaillent en étroite collaboration les unes avec les autres et sont le plus souvent situées au même endroit géographique.

Modèle Agile - Avantages et inconvénients

Les méthodes agiles sont récemment largement acceptées dans le monde du logiciel. Cependant, cette méthode peut ne pas toujours convenir à tous les produits. Voici quelques avantages et inconvénients du modèle Agile.

Les avantages du modèle Agile sont les suivants -

  • Est une approche très réaliste du développement logiciel.

  • Favorise le travail d'équipe et la formation croisée.

  • La fonctionnalité peut être développée rapidement et démontrée.

  • Les besoins en ressources sont minimaux.

  • Convient aux exigences fixes ou changeantes

  • Fournit des solutions de travail partielles précoces.

  • Bon modèle pour les environnements qui changent régulièrement.

  • Règles minimales, documentation facile à utiliser.

  • Permet le développement et la livraison simultanés dans un contexte global planifié.

  • Peu ou pas de planification requise.

  • Facile à gérer.

  • Donne de la flexibilité aux développeurs.

Les inconvénients du modèle Agile sont les suivants -

  • Ne convient pas à la gestion des dépendances complexes.

  • Plus de risque de durabilité, de maintenabilité et d'extensibilité.

  • Un plan global, un leader agile et une pratique de PM agile sont indispensables sans lesquels cela ne fonctionnera pas.

  • Une gestion stricte de la livraison dicte la portée, la fonctionnalité à livrer et les ajustements pour respecter les délais.

  • Dépend fortement de l'interaction avec le client, donc si le client n'est pas clair, l'équipe peut être conduite dans la mauvaise direction.

  • Il existe une dépendance individuelle très élevée, car une documentation minimale est générée.

  • Le transfert de technologie aux nouveaux membres de l'équipe peut être assez difficile en raison du manque de documentation.

le RAD (Rapid Application Development)Le modèle est basé sur le prototypage et le développement itératif sans planification spécifique. Le processus d'écriture du logiciel lui-même implique la planification nécessaire au développement du produit.

Le développement rapide d'applications se concentre sur la collecte des exigences des clients par le biais d'ateliers ou de groupes de discussion, les tests précoces des prototypes par le client à l'aide d'un concept itératif, la réutilisation des prototypes existants (composants), l'intégration continue et la livraison rapide.

Qu'est-ce que RAD?

Le développement rapide d'applications est une méthodologie de développement logiciel qui utilise une planification minimale en faveur du prototypage rapide. Un prototype est un modèle de travail qui est fonctionnellement équivalent à un composant du produit.

Dans le modèle RAD, les modules fonctionnels sont développés en parallèle sous forme de prototypes et sont intégrés pour créer le produit complet pour une livraison plus rapide du produit. Puisqu'il n'y a pas de planification préalable détaillée, il est plus facile d'incorporer les changements dans le processus de développement.

Les projets RAD suivent un modèle itératif et incrémental et disposent de petites équipes composées de développeurs, d'experts du domaine, de représentants des clients et d'autres ressources informatiques travaillant progressivement sur leur composant ou prototype.

L'aspect le plus important pour que ce modèle réussisse est de s'assurer que les prototypes développés sont réutilisables.

Conception de modèle RAD

Le modèle RAD répartit les phases d'analyse, de conception, de construction et de test en une série de cycles de développement courts et itératifs.

Voici les différentes phases du modèle RAD -

Modélisation commerciale

Le modèle commercial du produit en cours de développement est conçu en termes de flux d'informations et de distribution d'informations entre différents canaux commerciaux. Une analyse commerciale complète est effectuée pour trouver les informations vitales pour l'entreprise, comment elles peuvent être obtenues, comment et quand les informations sont-elles traitées et quels sont les facteurs qui contribuent à la réussite du flux d'informations.

Modélisation des données

Les informations recueillies lors de la phase de modélisation métier sont revues et analysées pour former des ensembles d'objets de données vitaux pour l'entreprise. Les attributs de tous les ensembles de données sont identifiés et définis. La relation entre ces objets de données est établie et définie en détail en fonction du modèle économique.

Modélisation de processus

Les ensembles d'objets de données définis dans la phase de modélisation des données sont convertis pour établir le flux d'informations commerciales nécessaires pour atteindre des objectifs commerciaux spécifiques selon le modèle commercial. Le modèle de processus pour toute modification ou amélioration des ensembles d'objets de données est défini dans cette phase. Des descriptions de processus pour ajouter, supprimer, récupérer ou modifier un objet de données sont données.

Génération d'applications

Le système réel est construit et le codage est effectué à l'aide d'outils d'automatisation pour convertir les modèles de processus et de données en prototypes réels.

Test et chiffre d'affaires

Le temps de test global est réduit dans le modèle RAD car les prototypes sont testés indépendamment à chaque itération. Cependant, le flux de données et les interfaces entre tous les composants doivent être soigneusement testés avec une couverture de test complète. Étant donné que la plupart des composants de programmation ont déjà été testés, cela réduit le risque de problèmes majeurs.

L'illustration suivante décrit le modèle RAD en détail.

Modèle RAD Vs SDLC traditionnel

Le SDLC traditionnel suit des modèles de processus rigides mettant l'accent sur l'analyse et la collecte des exigences avant le début du codage. Cela met la pression sur le client pour qu'il approuve les exigences avant le début du projet et le client ne perçoit pas le produit car il n'y a pas de version fonctionnelle disponible pendant une longue période.

Le client peut avoir besoin de quelques modifications après avoir vu le logiciel. Cependant, le processus de changement est assez rigide et il peut ne pas être possible d'intégrer des changements majeurs dans le produit dans le SDLC traditionnel.

Le modèle RAD se concentre sur la livraison itérative et incrémentale de modèles de travail au client. Il en résulte une livraison rapide au client et une implication du client pendant tout le cycle de développement du produit, ce qui réduit le risque de non-conformité avec les exigences réelles des utilisateurs.

Modèle RAD - Application

Le modèle RAD peut être appliqué avec succès aux projets dans lesquels une modularisation claire est possible. Si le projet ne peut pas être divisé en modules, RAD peut échouer.

Les pointeurs suivants décrivent les scénarios typiques dans lesquels RAD peut être utilisé -

  • RAD ne doit être utilisé que lorsqu'un système peut être modulaire pour être livré de manière incrémentielle.

  • Il doit être utilisé s'il existe une haute disponibilité des concepteurs pour la modélisation.

  • Il ne doit être utilisé que si le budget permet l'utilisation d'outils de génération de code automatisés.

  • Le modèle RAD SDLC ne doit être choisi que si des experts du domaine sont disponibles avec des connaissances métier pertinentes.

  • Doit être utilisé lorsque les exigences changent au cours du projet et que les prototypes de travail doivent être présentés au client en petites itérations de 2-3 mois.

Modèle RAD - Avantages et inconvénients

Le modèle RAD permet une livraison rapide car il réduit le temps de développement global en raison de la réutilisabilité des composants et du développement parallèle. RAD ne fonctionne bien que si des ingénieurs hautement qualifiés sont disponibles et que le client s'engage également à réaliser le prototype ciblé dans les délais impartis. S'il y a un manque d'engagement de part et d'autre, le modèle peut échouer.

Les avantages du modèle RAD sont les suivants -

  • Des exigences changeantes peuvent être adaptées.

  • Les progrès peuvent être mesurés.

  • Le temps d'itération peut être court avec l'utilisation d'outils RAD puissants.

  • Productivité avec moins de monde en peu de temps.

  • Temps de développement réduit.

  • Augmente la réutilisabilité des composants.

  • Des examens initiaux rapides ont lieu.

  • Encourage les commentaires des clients.

  • L'intégration dès le début résout de nombreux problèmes d'intégration.

Les inconvénients du modèle RAD sont les suivants -

  • Dépendance à des membres de l'équipe techniquement solides pour identifier les besoins de l'entreprise.

  • Seul un système modulable peut être construit à l'aide de RAD.

  • Nécessite des développeurs / concepteurs hautement qualifiés.

  • Forte dépendance aux compétences en modélisation.

  • Inapplicable aux projets moins chers car le coût de la modélisation et de la génération automatisée de code est très élevé.

  • La complexité de gestion est plus.

  • Convient aux systèmes basés sur des composants et évolutifs.

  • Nécessite l'implication de l'utilisateur tout au long du cycle de vie.

  • Convient aux projets nécessitant des temps de développement plus courts.

Le prototypage logiciel fait référence à la construction de prototypes d'applications logicielles qui affichent les fonctionnalités du produit en cours de développement, mais peuvent ne pas réellement contenir la logique exacte du logiciel d'origine.

Le prototypage logiciel devient très populaire en tant que modèle de développement logiciel, car il permet de comprendre les exigences des clients à un stade précoce du développement. Il permet d'obtenir des commentaires précieux du client et aide les concepteurs et les développeurs de logiciels à comprendre ce que l'on attend exactement du produit en cours de développement.

Qu'est-ce que le prototypage logiciel?

Prototype est un modèle de logiciel fonctionnel avec des fonctionnalités limitées. Le prototype ne contient pas toujours la logique exacte utilisée dans l'application logicielle réelle et représente un effort supplémentaire à prendre en compte dans l'estimation de l'effort.

Le prototypage est utilisé pour permettre aux utilisateurs d'évaluer les propositions des développeurs et de les essayer avant la mise en œuvre. Cela aide également à comprendre les exigences spécifiques à l'utilisateur et qui peuvent ne pas avoir été prises en compte par le développeur lors de la conception du produit.

Voici une approche par étapes expliquée pour concevoir un prototype de logiciel.

Identification des exigences de base

Cette étape consiste à comprendre les exigences de base du produit, notamment en termes d'interface utilisateur. Les détails les plus complexes de la conception interne et les aspects externes tels que les performances et la sécurité peuvent être ignorés à ce stade.

Développement du prototype initial

Le prototype initial est développé à ce stade, où les exigences très basiques sont présentées et les interfaces utilisateur sont fournies. Ces fonctionnalités peuvent ne pas fonctionner exactement de la même manière en interne dans le logiciel développé. Tandis que, les solutions de contournement sont utilisées pour donner le même aspect et la même sensation au client dans le prototype développé.

Examen du prototype

Le prototype développé est ensuite présenté au client et aux autres acteurs importants du projet. Les commentaires sont collectés de manière organisée et utilisés pour d'autres améliorations du produit en cours de développement.

Réviser et améliorer le prototype

La rétroaction et les commentaires d'examen sont discutés au cours de cette étape et certaines négociations ont lieu avec le client en fonction de facteurs tels que - les contraintes de temps et de budget et la faisabilité technique de la mise en œuvre réelle. Les modifications acceptées sont à nouveau intégrées dans le nouveau prototype développé et le cycle se répète jusqu'à ce que les attentes du client soient satisfaites.

Les prototypes peuvent avoir des dimensions horizontales ou verticales. Un prototype horizontal affiche l'interface utilisateur du produit et donne une vue plus large de l'ensemble du système, sans se concentrer sur les fonctions internes. Un prototype vertical de l'autre côté est une élaboration détaillée d'une fonction spécifique ou d'un sous-système du produit.

Le but du prototype horizontal et vertical est différent. Les prototypes horizontaux sont utilisés pour obtenir plus d'informations sur le niveau de l'interface utilisateur et les exigences métier. Il peut même être présenté dans les démos de vente pour faire des affaires sur le marché. Les prototypes verticaux sont de nature technique et sont utilisés pour obtenir des détails sur le fonctionnement exact des sous-systèmes. Par exemple, les exigences de base de données, les interactions et les charges de traitement des données dans un sous-système donné.

Prototypage logiciel - Types

Il existe différents types de prototypes logiciels utilisés dans l'industrie. Voici les principaux types de prototypage logiciel largement utilisés -

Jetable / Prototypage rapide

Le prototypage jetable est également appelé prototypage rapide ou fermé. Ce type de prototypage demande très peu d'efforts avec un minimum d'analyse des exigences pour construire un prototype. Une fois que les exigences réelles sont comprises, le prototype est jeté et le système réel est développé avec une compréhension très claire des exigences des utilisateurs.

Prototypage évolutif

Le prototypage évolutif, également appelé prototypage de maquette, est basé sur la construction de prototypes fonctionnels réels avec une fonctionnalité minimale au début. Le prototype développé constitue le cœur des futurs prototypes sur lesquels l'ensemble du système est construit. En utilisant le prototypage évolutif, les exigences bien comprises sont incluses dans le prototype et les exigences sont ajoutées au fur et à mesure qu'elles sont comprises.

Prototypage incrémental

Le prototypage incrémental fait référence à la construction de plusieurs prototypes fonctionnels des différents sous-systèmes, puis à l'intégration de tous les prototypes disponibles pour former un système complet.

Prototypage extrême

Le prototypage extrême est utilisé dans le domaine du développement Web. Il se compose de trois phases séquentielles. Tout d'abord, un prototype de base avec toutes les pages existantes est présenté au format HTML. Ensuite, le traitement des données est simulé à l'aide d'une couche de services prototype. Enfin, les services sont implémentés et intégrés au prototype final. Ce processus est appelé Extreme Prototyping utilisé pour attirer l'attention sur la deuxième phase du processus, où une interface utilisateur entièrement fonctionnelle est développée avec très peu de considération pour les services réels.

Prototypage logiciel - Application

Le prototypage logiciel est le plus utile dans le développement de systèmes ayant un niveau élevé d'interactions avec les utilisateurs tels que les systèmes en ligne. Les systèmes qui nécessitent que les utilisateurs remplissent des formulaires ou passent par divers écrans avant que les données ne soient traitées peuvent utiliser le prototypage très efficacement pour donner l'apparence exacte avant même que le logiciel réel ne soit développé.

Les logiciels qui impliquent trop de traitement de données et dont la plupart des fonctionnalités sont internes avec très peu d'interface utilisateur ne bénéficient généralement pas du prototypage. Le développement de prototypes peut être une surcharge supplémentaire dans de tels projets et peut nécessiter beaucoup d'efforts supplémentaires.

Prototypage logiciel - Avantages et inconvénients

Le prototypage logiciel est utilisé dans des cas typiques et la décision doit être prise avec beaucoup de soin afin que les efforts consacrés à la construction du prototype ajoutent une valeur considérable au logiciel final développé. Le modèle a ses propres avantages et inconvénients présentés comme suit.

Les avantages du modèle de prototypage sont les suivants -

  • Implication accrue des utilisateurs dans le produit avant même sa mise en œuvre.

  • Puisqu'un modèle de travail du système est affiché, les utilisateurs ont une meilleure compréhension du système en cours de développement.

  • Réduit le temps et les coûts car les défauts peuvent être détectés beaucoup plus tôt.

  • Des commentaires plus rapides des utilisateurs sont disponibles, ce qui conduit à de meilleures solutions.

  • Les fonctionnalités manquantes peuvent être facilement identifiées.

  • Des fonctions déroutantes ou difficiles peuvent être identifiées.

Les inconvénients du modèle de prototypage sont les suivants:

  • Risque d'analyse insuffisante des besoins en raison d'une trop grande dépendance au prototype.

  • Les utilisateurs peuvent être confus dans les prototypes et les systèmes réels.

  • En pratique, cette méthodologie peut accroître la complexité du système car la portée du système peut s'étendre au-delà des plans originaux.

  • Les développeurs peuvent essayer de réutiliser les prototypes existants pour construire le système réel, même si cela n'est pas techniquement réalisable.

  • L'effort investi dans la construction de prototypes peut être trop important s'il n'est pas correctement surveillé.