Article original : SDLC Guide – Software Development Life Cycle Phases and Methodologies

Par Jonathan Sexton

Lorsque j'ai décidé d'apprendre à coder il y a presque quatre ans, je n'avais jamais entendu parler, et encore moins pensé, au cycle de vie du développement logiciel.

En tant que tout nouveau développeur, je me concentrais sur l'apprentissage des technologies qui m'aideraient à décrocher ce premier emploi de développeur tant convoité, et non sur les nuances du fonctionnement de ces équipes.

Lorsque j'ai finalement découvert ces concepts, je pensais qu'ils seraient inutiles pour moi parce que je me considérais comme un développeur web et non comme un développeur logiciel.

J'ai depuis appris que cela ne pouvait pas être plus éloigné de la vérité et que ces principes/pratiques jouent un rôle important dans mes activités quotidiennes (que je m'en rende compte ou non).

J'ai la chance de voir comment le code que j'écris, les fonctionnalités que je construis et les bugs que j'introduis involontairement (plus que je ne veux l'admettre) affectent l'utilisateur final et son expérience. Cette expérience a aidé à façonner ma façon de penser le processus de construction de produits et de résolution de problèmes pour mes utilisateurs.

J'ai eu le temps de réfléchir aux différences (et similitudes) que chacune de ces approches offre. Au cœur de chacune d'elles, l'objectif est de livrer un logiciel de haute qualité de manière aussi efficace et aussi rentable que possible.

Professionnellement, je n'ai utilisé qu'une ou deux de ces méthodologies. Mais je trouve toujours de la valeur dans au moins une compréhension basique de chacune d'elles.

Toutes ces méthodologies suivent une série de phases similaires à ce diagramme :

Image Analyse des Exigences -> Conception -> Implémentation -> Test -> Évolution

Voici donc les méthodes du cycle de vie du développement logiciel (dans un ordre quelconque) :

Examinons les différences et les similitudes de chaque méthode.

Lean

La méthodologie Lean repose fortement sur sept principes et en est composée.

Dans un ordre non spécifique, ils sont :

  1. Éliminer le Gâchis
  2. Amplifier l'Apprentissage
  3. Décider le Plus Tard Possible
  4. Livrer le Plus Rapidement Possible
  5. Autonomiser l'Équipe
  6. Construire l'Intégrité
  7. Voir/Optimiser l'Ensemble

Chaque principe a un objectif spécifique avec des avantages qui se complètent.

L'élimination du gâchis (fonctionnalités supplémentaires, travail incomplet, engagements managériaux, etc.) crée plus de valeur pour le client, ce qui, à son tour, améliore la satisfaction.

L'amplification de l'apprentissage permet aux équipes de réinvestir dans leur capacité à livrer des produits aux clients.

Décider le plus tard possible fait référence à toutes les décisions majeures, donnant aux équipes une option basée ou une approche basée sur un ensemble. Cela permet aux équipes de recueillir des faits plutôt que des opinions pour aider à influencer les décisions lorsqu'elles sont prises.

Livrer le plus rapidement possible est explicite - construire le produit aussi rapidement que possible pour le livrer aux clients pour évaluation/itération.

Dans un scénario typique, les managers distribuent les tâches/travaux aux développeurs. Dans la méthodologie Lean, les développeurs "apprennent" aux managers à écouter les "personnes sur le terrain", influençant ainsi les décisions/choix de la direction.

Cela aide les équipes à se sentir plus autonomes pour parler des idées et des solutions.

Faire de l'intégrité une règle plutôt qu'une exception signifie que le client a confiance dans le système en cours de construction. Le client sait que le système est construit pour résister à la quantité appropriée de croissance et de "stretching" si nécessaire.

J'aime penser à la partie intégrité de la même manière que de s'asseoir sur une chaise. Lorsque vous vous asseyez sur la chaise, vous croyez qu'elle a été construite avec le meilleur matériau qui vous soutiendra chaque fois que vous vous asseyez dessus pour la durée de vie de la chaise. Le client doit avoir cette même confiance dans le produit en cours de construction.

Enfin, voir et optimiser l'ensemble fait référence à l'intégralité du système en cours de construction. En optimisant pour l'ensemble, nous considérons le logiciel non pas comme une somme de nombreux composants, mais comme une grande entité optimisée pour l'efficacité.

Cela signifie que pendant le développement, le produit est divisé en morceaux gérables et que les bugs involontaires sont non seulement découverts mais résolus rapidement.

Agile

C'est l'approche "échouer rapidement" pour construire des logiciels.

Elle met l'accent sur des versions petites et incrémentielles avec des cycles de version en cours. À chaque itération, les équipes s'efforcent d'identifier et de résoudre les petits problèmes avant qu'ils ne deviennent de gros problèmes.

Cela signifie également que les équipes doivent engager les parties prenantes (personnes/organisations que le code peut finalement affecter, telles que les managers, les responsables techniques, les CTO et les clients) pour obtenir leurs commentaires.

Si vous êtes freelance, vos parties prenantes seraient vos clients - en fin de compte, vous devez vous assurer de leur satisfaction avec le travail avant de passer à autre chose.

Agile est techniquement une ramification de la méthodologie Lean avec quelques différences notables - principalement, elle priorise la satisfaction du client dès le départ et permet aux équipes de répondre rapidement aux commentaires des clients.

Bien que cela dépasse le cadre de cet article, il existe un autre cadre plus complexe au sein d'Agile appelé SCRUM. Cette méthodologie est utilisée pour des projets très grands et extrêmement complexes et a même été utilisée en dehors du développement logiciel.

Waterfall

La méthodologie Waterfall est, selon la plupart des comptes, la plus ancienne de la liste. Elle n'a jamais été destinée à être un modèle pour le développement logiciel et a commencé dans les mondes de la construction et de la fabrication.

Cette approche est simple dans sa structure - terminer toutes les parties d'une phase avant de passer à la phase suivante avec plus d'élan vers la fin du projet à mesure que les étapes sont complétées. Le début (sauf pour la première) et la fin de chaque étape dépendent de la fin/du transfert d'informations de l'étape précédente.

Selon l'approche Waterfall, chaque étape a son propre plan de projet rigide qui se termine par des tests pour le travail précédemment terminé. Il convient de noter que cette approche n'est pas recommandée pour les projets plus grands/de plus longue durée en raison de la rigidité mentionnée ci-dessus.

Pensez à la genèse de cette méthodologie et vous la comprendrez mieux. Elle vient du monde de la construction/fabrication où il est courant de compléter une phase à la fois. Pendant la construction d'une maison, vous ne commenceriez pas à installer la plomberie avant que la charpente ne soit mise en place.

Ce n'est pas généralement ainsi que fonctionne le développement logiciel. Comme nous le savons tous, il devient parfois nécessaire de revenir sur une phase qui était précédemment considérée comme terminée.

Itératif

Cela est connu comme l'approche "répétitive" ou l'approche "améliorer la prochaine fois" en raison des différentes opportunités qu'elle offre pour améliorer le produit à chaque itération du cycle.

Je suis partial (comme nous le sommes tous :D) mais cela se trouve être mon cycle de vie préféré pour le développement. Je crois qu'il fonctionne mieux pour ma situation actuelle, à la fois dans mon travail freelance et ma carrière, car il me permet de "avancer tout en améliorant les choses".

Avec l'approche itérative, les équipes mettent en œuvre une solution, testent cette solution, évaluent son efficacité/débit, puis identifient d'autres domaines à améliorer. Cela se produit pour chaque cycle (itération) du processus de développement.

Avec chaque version publiée vient une autre itération jusqu'à ce que le produit final soit terminé et prêt pour le déploiement auprès des utilisateurs.

L'une des grandes caractéristiques de l'approche itérative est que vous et votre équipe obtenez une version fonctionnelle du logiciel tôt dans le processus de développement. Cela peut être particulièrement utile à montrer aux parties prenantes pour évaluer leur réponse/commentaires.

L'un des grands inconvénients de cette approche est qu'elle peut consommer une grande quantité de ressources très rapidement. Imaginez toutes les personnes, les heures, les corrections de bugs et les salaires qui entrent dans chaque itération du cycle de développement et vous aurez une bonne image de l'utilisation des ressources.

Au sein de cette approche se trouve un sous-ensemble de principes développés par Rational Software Corporation (rachetée par IBM) appelé le Rational Unified Process (R.U.P.) qui se compose de 4 phases :

  • Initialisation
  • Élaboration
  • Construction
  • Transition (version du produit)

Cet ensemble de principes est destiné à être flexible et adapté aux besoins de chaque équipe qui l'utilise.

Spiral

La méthodologie Spiral est probablement la plus flexible des six. C'est une méthodologie construite sur les risques - les identifier et les nier. Le risque (identification et aversion) guide chaque décision dans ce modèle. Elle est divisée en quatre sous-phases :

  • Planification (objectifs)
  • Analyse des Risques (identifier les obstacles possibles)
  • Développement et Test (version actuelle et suivante)
  • Évaluation (revue de la phase actuelle et plan pour la phase suivante)

Chaque itération de chaque phase commence par la planification de la phase suivante. De cette façon, les risques potentiels sont identifiés avant d'être rencontrés. Cela permet également un plan d'action lorsque lesdits risques surviennent.

Pendant les phases, les équipes travaillent également à atténuer ces risques et leur impact sur les futures itérations du développement en spirale.

À mesure que le processus de développement continue, chacune de ces quatre sous-phases est répétée à la manière d'une spirale. Cela permet plusieurs tours de raffinement pour chaque sous-phase jusqu'à la fin.

DevOps

Si vous faites une recherche rapide, vous trouverez une abondance d'informations sur cette méthode de cycle de vie de développement. C'est le nouveau venu qui réunit les équipes de développement logiciel et les équipes d'exploitation de la technologie de l'information dans le même groupe.

Ces équipes travaillent en conjonction pour fournir des mises à jour petites mais impactantes aux produits qui arrivent à un rythme fréquent. À son tour, cela crée une boucle de feedback et d'amélioration continue qui guide le développement.

Cette méthodologie particulière est connue pour automatiser les parties manuelles du développement également (pensez au déploiement).

L'objectif global de cette méthodologie est, comme la plupart des autres, de raccourcir le cycle de vie du développement et de fournir des produits de qualité.

L'un des inconvénients de cette méthodologie est le changement significatif de mentalité et de culture au sein d'une organisation. Les équipes qui pouvaient être habituées à travailler sur de nombreuses choses voient leurs tâches réduites à une ou deux seulement.

Par exemple, un développeur généraliste peut constater qu'il est maintenant chargé uniquement de la partie test ou de la partie expérience utilisateur finale.

Conclusion

une ampoule sur un livre _Photo par [Unsplash](https://unsplash.com/@clever_visuals?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Clever Visuals sur <a href="https://unsplash.com/s/photos/bright-idea?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

J'espère que vous pouvez maintenant voir l'importance et les avantages de chacune de ces méthodologies. Chacune d'elles possède ses propres forces et faiblesses.

Elles sont, à leur niveau le plus basique, un ensemble de directives et de principes qui cherchent à livrer un travail de haute qualité et efficace aux parties prenantes.

Lorsque j'ai commencé à apprendre à coder, je n'avais pas de mentor. En partageant ce que j'ai appris, j'espère aider ceux qui apprennent à coder quand et où ils le peuvent.

Je veux partager autant d'informations et d'expérience que possible avec d'autres développeurs. Si vous apprenez à coder par vous-même ou si vous êtes un développeur expérimenté, j'espère que cet article aide, même de manière modeste.

Consultez mon blog où je publie fréquemment des articles sur le développement web.

Pendant que vous y êtes, pourquoi ne pas vous inscrire à ma newsletter ? Vous pouvez le faire en haut à droite de la page principale du blog. J'aime envoyer des articles intéressants (les miens et ceux des autres), des ressources et des outils pour les développeurs de temps en temps.

Si vous avez des questions sur cet article ou simplement en général, mes DM sont ouverts -- venez dire bonjour sur Twitter ou sur l'un de mes autres comptes de réseaux sociaux que vous pouvez trouver sous l'inscription à la newsletter sur la page principale ou sur mon profil ici :)

Passez une journée formidable et bon codage, ami !