10.2 : Modèle du cycle de vie du développement des systèmes (SDLC)

Modèle du cycle de vie du développement des systèmes (SDLC)

Le SDLC a été développé pour la première fois dans les années 1960 pour gérer les grands projets associés aux systèmes d'entreprise exécutés sur des ordinateurs centraux. Il s'agit d'un processus très structuré conçu pour gérer de grands projets nécessitant les efforts de nombreuses personnes, y compris des professionnels techniques, commerciaux et de support. Ces projets sont souvent coûteux à mettre en œuvre et ont un impact important sur l'organisation. Un projet qui échoue ou une mauvaise décision commerciale de choisir un mauvais projet à financer peut être une catastrophe commerciale ou financière pour une organisation.

Le SDLC est un modèle définissant un processus composé d'un ensemble de phases de planification, d'analyse, de conception, de mise en œuvre et de maintenance. Le chapitre 1 explique qu'un système d'information (SI) comprend du matériel, des logiciels, des bases de données, des réseaux, des processus et des personnes. Le SDLC a souvent été utilisé pour gérer un projet de SI qui peut inclure un, certains ou tous les éléments d'un SI. Passons en revue chacune des cinq phases d'un SDLC, comme illustré à la Figure 10.1 :

Figure 10.1 - Modèle de cycle de vie du développement logiciel. L'image de Ly-Huong Pham, Ph.D. est sous licence CC BY NC

1. Planification. Dans cette phase, une demande est initiée par une personne qui agit en tant que sponsor de cette idée. Une petite équipe est constituée pour effectuer une évaluation préliminaire du mérite et de la faisabilité de la demande. Les objectifs de cette phase sont les suivants :

• Déterminer dans quelle mesure la demande correspond à la stratégie ou aux objectifs commerciaux de l'entreprise.
• Réaliser une analyse de faisabilité, qui inclut une analyse de la faisabilité technique (est-il possible de la créer ?) , la faisabilité économique (pouvons-nous nous le permettre ?) , et la faisabilité juridique (sommes-nous autorisés à le faire ?).
• Pour recommander une réponse positive ou négative à la demande. Si c'est possible, une proposition de concept est également produite pour approbation par la direction.

2. Analyse. Une fois la proposition de concept approuvée, le projet est formalisé avec une nouvelle équipe de projet (y compris la phase précédente). En utilisant la proposition de concept comme point de départ, les membres du projet travaillent avec différents groupes de parties prenantes pour déterminer les exigences spécifiques du nouveau système. Aucune programmation ou développement n'est effectué à cette étape. Les objectifs de cette phase sont les suivants :

• Identifiez et interrogez les principales parties prenantes.
• Documenter les principales procédures
• Définir les exigences en matière de données
• Produire un document sur les exigences du système à la suite de cette phase. Cela contient les détails nécessaires pour commencer la conception du système.

3. Conception. Une fois les exigences du système approuvées, l'équipe peut être reconfigurée pour intégrer davantage de membres. Cette phase vise à permettre à l'équipe de projet de prendre le document sur les exigences du système créé lors de la phase précédente et de développer les détails techniques spécifiques requis pour le système. Les objectifs sont les suivants :

• Traduisez les exigences de l'entreprise en exigences techniques spécifiques
• Conception de l'interface utilisateur, de la base de données, des entrées et sorties de données et des rapports
• Produire un document de conception du système à la suite de cette phase. Ce document contiendra tout ce dont un programmeur aura besoin pour créer le système.

4. Mise en œuvre. Une fois que la conception d'un système est approuvée, le code logiciel est finalement écrit lors de la phase de programmation, et l'effort de développement d'autres éléments tels que le matériel se déroule également. L'objectif est de créer un système de travail initial. Les objectifs sont les suivants :

• Développez le code logiciel et les autres composants du SI. En utilisant le document de conception du système comme guide, les développeurs commencent à coder ou à développer tous les composants du projet SI.
• Testez le système de travail grâce à une série de tests structurés tels que :
  • Le premier est un test unitaire, qui teste des parties individuelles du code pour détecter les erreurs ou les bogues.
  • Ensuite, il y a un test du système, au cours duquel les différents composants du système sont testés pour s'assurer qu'ils fonctionnent correctement ensemble.
  • Enfin, le test d'acceptation par l'utilisateur permet à ceux qui utiliseront le logiciel de tester le système afin de s'assurer qu'il répond à leurs normes.
  • Testez à nouveau les correctifs de manière itérative pour corriger les bogues, les erreurs ou les problèmes détectés lors des tests.
  • Former les utilisateurs
  • Fournir de la documentation
  • Effectuez les conversions nécessaires de n'importe quel système précédent vers le nouveau système.
  • Produire, par conséquent, le système de travail initial qui répond aux exigences définies lors de la phase d'analyse et à la conception développée lors de la phase de conception.

5. Entretien. Cette phase a lieu une fois que la phase de mise en œuvre est terminée. Au cours de cette phase, le système doit disposer d'un processus de soutien structuré pour :

• Signaler des bogues
• Déployer des correctifs
• Accepter les demandes de nouvelles fonctionnalités
• Évaluer les priorités des bogues signalés ou des fonctionnalités demandées à implémenter
• Définissez un calendrier prévisible et régulier pour publier les mises à jour du système et effectuer des sauvegardes.
• Éliminez les données et tout ce qui n'est plus nécessaire

Les organisations peuvent combiner ou subdiviser ces phases en fonction de leurs besoins. Par exemple, au lieu d'une seule phase, la planification, une organisation peut choisir d'avoir deux phases : initiation, conception ; ou de diviser la mise en œuvre en deux phases : mise en œuvre et test.

Modèle Waterfall

Un modèle spécifique basé sur le SDLC est le modèle Waterfall, dont le nom est souvent considéré comme le même que SDLC. Il est utilisé pour gérer les projets logiciels tels que décrits à la figure 10.2 avec cinq phases : exigences, conception, mise en œuvre, vérification et maintenance. Ce modèle souligne que chaque phase doit être terminée avant que la suivante puisse commencer (d'où le nom de cascade). Par exemple, les modifications des exigences ne sont pas autorisées une fois que la phase de mise en œuvre a commencé, ou des modifications doivent être recherchées et approuvées dans le cadre d'un processus de modification. Ils peuvent obliger le projet à redémarrer à partir de la phase d'exigences puisque de nouvelles exigences doivent être approuvées, ce qui peut entraîner la révision de la conception avant le début de la phase de mise en œuvre.

Figure 10.2 Modèle de développement du système en cascade. Image de Peter Kemp/Paul Smit est sous licence CC BY 3.0

La structure rigide du modèle en cascade a été critiquée pour sa rigidité et sa réticence à prendre des risques pour éviter de revenir aux phases précédentes. Cependant, une telle structure présente également des avantages. Certains avantages et inconvénients du SDLC et de Waterfall sont les suivants :

Avantages et inconvénients du SDLC et de Waterfall

AVANTAGES	Désavantages
Le processus robuste de contrôle et de suivi des modifications afin de minimiser le nombre de risques peut faire dérailler le projet sans le savoir.	Prenez le temps de tout enregistrer, ce qui entraîne des coûts et du temps supplémentaires.
Des processus standard et transparents facilitent la gestion des grandes équipes.	Trop de temps passé à assister à des réunions, à demander une approbation, etc., ce qui entraîne des coûts et du temps supplémentaires.
La documentation réduit les risques de perte de personnel et facilite l'ajout de personnes au projet.	Certains membres n'aiment pas passer du temps à écrire, ce qui augmente le temps nécessaire à la réalisation d'un projet.
Il est plus facile de retracer un problème dans le système jusqu'à sa racine chaque fois que des erreurs sont détectées, même après la fin du projet.	Il est difficile d'intégrer les modifications ou les commentaires des clients car le projet doit revenir à une ou plusieurs phases précédentes, ce qui amène les équipes à hésiter à prendre des risques.

D'autres modèles sont développés au fil du temps pour répondre à ces critiques. Nous aborderons deux autres modèles : le développement rapide d'applications et le modèle agile, en tant qu'approches différentes du SDLC.

Développement rapide d'applications (RAD)

Le développement rapide d'applications (RAD) est une méthodologie de développement de logiciels (ou de développement de systèmes) qui se concentre moins sur la planification et l'intégration des changements sur une base continue. RAD s'attache à créer rapidement un modèle de fonctionnement du logiciel ou du système, à recueillir les commentaires des utilisateurs et à mettre à jour le modèle de travail. Après plusieurs itérations de développement, une version finale est développée et mise en œuvre. Passons en revue les quatre phases du modèle RAD, comme illustré à la figure 10.3.

Fig 10.3 Le modèle de développement rapide d'applications Image est sous licence dans le domaine public.

1. Planification des besoins. Cette phase est similaire aux phases de planification, d'analyse et de conception du SDLC.
2. Design utilisateur. Au cours de cette phase, les représentants des utilisateurs travaillent avec les analystes, les concepteurs et les programmeurs du système pour créer de manière interactive la conception du système. L'une des techniques permettant de travailler avec toutes ces différentes parties prenantes est la session de développement conjoint d'applications (JAD). Une session JAD permet à tous les utilisateurs concernés qui interagissent avec les systèmes sous différents angles, ainsi qu'à d'autres parties prenantes clés, y compris les développeurs, d'avoir une discussion structurée sur la conception du système. Les objectifs sont de permettre aux utilisateurs de comprendre et d'adopter le modèle de travail et aux développeurs de comprendre comment le système doit fonctionner du point de vue de l'utilisateur pour offrir une expérience utilisateur positive.
3. Bâtiment. Dans la phase de construction, les tâches sont similaires à celles de la phase de mise en œuvre du SDLC. Les développeurs continuent de travailler de manière interactive avec les utilisateurs pour intégrer leurs commentaires lorsqu'ils interagissent avec le modèle de travail en cours de développement. Il s'agit d'un processus interactif, et des modifications peuvent être apportées au fur et à mesure que les développeurs travaillent sur le programme. Cette étape est exécutée parallèlement à l'étape de conception utilisateur de manière itérative jusqu'à ce qu'une version acceptable du produit soit développée.
4. Passage. Cette étape est similaire à certaines tâches de la phase de mise en œuvre du SDLC. Le système est mis en service ou entièrement déployé. Toutes les étapes nécessaires pour passer de l'état précédent à l'utilisation du nouveau système sont effectuées ici.

Par rapport au modèle SDLC ou Waterfall, la méthodologie RAD est beaucoup plus compressée. La plupart des étapes du SDLC sont combinées et l'accent est mis sur la participation et l'itération des utilisateurs. Cette méthodologie est mieux adaptée aux petits projets et présente l'avantage supplémentaire de permettre aux utilisateurs de fournir des commentaires tout au long du processus. Le SDLC nécessite davantage de documentation et une attention particulière aux détails et convient parfaitement aux grands projets gourmands en ressources. RAD convient mieux aux projets qui nécessitent moins de ressources et qui doivent être développés rapidement. Voici certains des avantages et des inconvénients du RAD :

Avantages et inconvénients du RAD

AVANTAGES	Désavantages
Améliorez la qualité grâce à la fréquence des interactions avec les utilisateurs	Risques liés à une faible mise en œuvre de fonctionnalités non visibles pour les utilisateurs, telles que la sécurité
Réduire les risques de refus des utilisateurs d'accepter le produit fini	Manque de contrôle sur les modifications du système en raison de la rapidité d'exécution d'une version fonctionnelle pour résoudre les problèmes des utilisateurs.
Améliorez les chances d'achèvement dans les délais et le budget grâce aux mises à jour des utilisateurs en temps réel, évitant ainsi les surprises pendant le développement.	Le manque de conception dû aux modifications apportées au système peut avoir des répercussions inconscientes sur d'autres parties du système.
Augmentez le temps d'interaction entre les développeurs/experts et	Des ressources limitées en tant que développeurs sont bloquées, ce qui pourrait ralentir d'autres projets.
Idéal pour les équipes de projet de petite et moyenne taille	Difficile de s'adapter à de grandes équipes

Méthodes de développement agiles

Les méthodologies agiles sont un groupe de méthodologies qui utilisent des changements progressifs axés sur la qualité et le souci du détail. Chaque incrément est publié dans un délai spécifié (appelé « boîte de temps »), ce qui crée un calendrier de publication régulier avec des objectifs spécifiques. Bien qu'ils soient considérés comme une méthodologie distincte de la RAD, ils partagent certains des mêmes principes : développement itératif, interaction utilisateur et évolutivité. Les méthodologies agiles sont basées sur le « Manifeste agile », publié pour la première fois en 2001.

Les caractéristiques des méthodes agiles incluent :

• de petites équipes interfonctionnelles comprenant des membres de l'équipe de développement et des utilisateurs ;
• des réunions quotidiennes sur l'état d'avancement du projet pour discuter de l'état actuel du projet ;
• de courts délais (de quelques jours à une ou deux semaines) pour chaque modification à effectuer ; et
• À la fin de chaque itération, un projet de travail est réalisé pour le démontrer aux parties prenantes.

Essentiellement, l'approche Agile met davantage l'accent sur les tâches qui favorisent l'interaction, créent des versions de travail fréquentes, la collaboration entre clients et utilisateurs et une réponse rapide aux changements tout en mettant moins l'accent sur les processus et la documentation. L'objectif des méthodologies agiles est de fournir la flexibilité d'une approche itérative tout en garantissant un produit de qualité.

Il existe une variété de modèles conçus à l'aide de méthodologies agiles. Le modèle de développement Scrum en est un exemple.

Modèle de développement Scrum

Ce modèle convient aux petites équipes qui s'efforcent de produire un ensemble de fonctionnalités dans le cadre d'interactions à durée fixe, telles que des sprints de deux à quatre semaines. Passons en revue les quatre éléments clés d'un modèle Scrum, comme illustré sur la figure 10.4.

Figure 10.4. La méthode de gestion de projet Scrum. L'image de Lakeworks est sous licence CC BY-SA 4.0

1. Carnet de produits. Il s'agit d'une liste détaillée des travaux à effectuer. Tout le travail est hiérarchisé en fonction de critères tels que les risques, les dépendances, les tâches critiques, etc. Les développeurs sélectionnent leurs propres tâches et s'auto-organisent pour mener à bien le travail.
2. Carnet de commandes de sprint. Voici une liste du travail à effectuer lors du prochain sprint.
3. Sprint. Il s'agit d'un délai fixe, par exemple 1 jour, 2 semaines ou 4 semaines, comme convenu par l'équipe. Une réunion de progression quotidienne est appelée mêlée quotidienne, généralement une courte réunion de 10 à 15 minutes animée par un Scrum Master dont le rôle est de lever les obstacles pour l'équipe.
4. Incrément de fonctionnement du logiciel e. Il s'agit d'une version fonctionnelle qui est construite de manière incrémentielle avec les listes de répartition à la fin des sprints.

Méthode Lean

Une dernière méthodologie que nous aborderons est un concept relativement nouveau tiré du best-seller commercial The Lean Startup, d'Eric Reis.

Figue 10.5. La méthodologie Lean. David T. Bourgeois, Ph.D. est sous licence CC BY-SA 2.0

Cette méthodologie se concentre sur la prise d'une idée initiale et le développement d'un produit minimum viable (MVP). Le MVP est une application logicielle fonctionnelle avec juste assez de fonctionnalités pour démontrer l'idée qui sous-tend le projet. Une fois le MVP développé, il est remis aux utilisateurs potentiels pour examen. Les commentaires sur le MVP sont générés sous deux formes : (1) observation directe et discussion avec les utilisateurs, et (2) statistiques d'utilisation collectées à partir du logiciel lui-même. À l'aide de ces deux formes de feedback, l'équipe détermine si elle doit continuer dans la même direction ou repenser l'idée de base du projet, modifier les fonctions ou créer un nouveau MVP. Ce changement de stratégie est appelé pivot. Plusieurs versions du MVP sont développées, avec de nouvelles fonctions ajoutées à chaque fois en fonction des commentaires, jusqu'à ce qu'un produit final soit terminé.

La principale différence entre la méthodologie Lean et les autres méthodologies est que l'ensemble des exigences du système n'est pas connu au moment du lancement du projet. À mesure que chaque itération du projet est publiée, les statistiques et les commentaires recueillis sont utilisés pour déterminer les exigences. La méthodologie Lean fonctionne mieux dans un environnement entrepreneurial où une entreprise souhaite déterminer si son idée d'application logicielle mérite d'être développée.

Références :

Manifeste pour le développement de logiciels agiles (2001). Consulté le 10 décembre 2020 sur http://agilemanifesto.org/

La start-up Lean. Consulté le 9 décembre 2020 sur http://theleanstartup.com/