Objectifs de certification

DEVASC 200-901

• 1.4 Comparer les méthodes de développement de logiciels (agile, lean et waterfall)

• 1.3 Décrire les concepts de développement test-driven

• 1.6 Identifier les avantages des modèles de conception communs (MVC et Observer)

• 4.12 Identifier les principes des pratiques DevOps

Concepts de développement logiciel

Concevoir un logiciel consiste principalement à résoudre des problèmes avec du code informatique en se fondant sur une méthodologie.

La conception logicielle connait un cycle de vie avec des phases :

• méthodologie
• production de l’intrant de la phase suivante

1. Cycle de développement logiciel

• Phase 1. Exigences et analyse
• Phase 2. Conception
• Phase 3. Mise en oeuvre
• Phase 4. Test
• Phase 5. Déploiement
• Phase 6. Maintenance

1.1. Phase 1. Exigences et analyse

1.2. Phase 2. Conception

1.3. Phase 3. Mise en oeuvre

1.4. Phase 4. Test

1.5. Phase 5 Déploiement

1.6. Phase 6. Maintenance

2. Patrons de conception

2.1. Patrons de conception du GoF

En développement logiciel, un patron de conception (souvent appelé design pattern) est un arrangement caractéristique de modules et qui est reconnu comme une bonne pratique en réponse à un problème de conception d’un logiciel. Un patron de conception décrit une solution standard et utilisable dans la conception de différents logiciels.

Les patrons de conception ont été formellement reconnus en 1994 à la suite de la parution du livre “Design Patterns: Elements of Reusable Software”, co-écrit par quatre auteurs : Gamma, Helm, Johnson et Vlissides appelés collectivement le “Gang of Four - GoF”. Ce livre, devenu un best-seller, décrit vingt-trois patrons GoF et comment s’en servir.

Il existe trois familles de patrons de conception selon leur utilisation :

• créateurs : ils définissent comment faire l’instanciation et la configuration des classes et des objets ;
• structuraux : ils définissent comment organiser les classes d’un programme dans une structure plus large (séparant l’interface de l’implémentation) ;
• comportementaux : ils définissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités) et expliquent le fonctionnement des algorithmes impliqués.

Source : Patron de conception, Patrons de conception du GoF.

2.2. Patron Observer

Le patron observateur (Observer) est un des patrons de conception de la famille des patrons comportementaux du GoF.

Il est utilisé pour envoyer un signal à des modules qui jouent le rôle d’observateurs. En cas de notification (Notify), les observateurs effectuent alors l’action adéquate en fonction des informations qui parviennent depuis les modules qu’ils observent (les observables).

Source : Patron de conception Observateur

2.3. Patron Model-View-Controller (MVC)

Modèle-vue-contrôleur ou MVC est un patron d’architecture logicielle destiné aux interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le patron est composé de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.

• Un modèle (Model) contient les données à afficher.
• Une vue (View) contient la présentation de l’interface graphique.
• Un contrôleur (Controller) contient la logique concernant les actions effectuées par l’utilisateur.

Ce patron est utilisé par de nombreux frameworks pour applications Web tels que Ruby on Rails, Grails, ASP.NET MVC, Spring, Struts, Symfony, Apache Tapestry, Laravel, ou encore AngularJS.

Source : Patron de conception Modèle-Vue-Contrôleur (MVC)

Source de l’image : © Benoît Prieur / Wikimedia Commons

3. Méthodes de développement de logiciels

• En cascade (Waterfall)
• Agile
• Lean

3.1. Méthode de développement en cascade (Waterfall)

Le modèle en cascade, ou « waterfall » en anglais, est une organisation des activités d’un projet sous forme de phases linéaires et séquentielles, où chaque phase correspond à une spécialisation des tâches et dépend des résultats de la phase précédente. Il comprend les phases d’exigences, de conception, de mise en œuvre et de mise en service.

Source : Modèle en cascade

3.2. Manifeste Agile

Le Manifeste pour le développement agile de logiciels est un texte rédigé aux États-Unis en 2001 par dix-sept experts du développement logiciels. Ils estimaient que le taux important d’échecs des projets de développements logiciels était dû à la lourdeur des méthodes traditionnelles inspirées du génie civil et s’appuyant sur un cycle de développement en cascade.

Le Manifeste agile est constitué de quatre valeurs et de douze principes fondateurs.

Le développement agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu (méthode agile).

C’est à partir de ces réalités pratiques, et non pas sur la base d’une théorie globale ou structurante, que l’agilité progresse vers les sphères les plus hautes de l’organisation et participe à la création de ce que l’on peut appeler une culture agile de l’organisation.

Source : Manifeste agile

3.3. Méthode de développement Agile

• Scrum propose un ensemble réduit de pratiques concentrées sur le développement de l’adaptabilité par l’apprentissage et l’auto-organisation.
• Scrum s’appuie sur le découpage d’un projet en “sprints” (pointes de vitesse). Les sprints peuvent durer entre quelques heures et un mois (avec un sprint médian à deux semaines). Chaque sprint commence par une estimation suivie d’une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l’équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d’améliorer ses pratiques. Le flux de travail de l’équipe de développement est facilité par son auto-organisation, il n’y aura donc pas de gestionnaire de projet.
• L’apport méthodologique de l’“eXtreme Programming (XP)” réside dans la préconisation à pousser à l’extrême les principales pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation consensuelle, de planification pilotée par l’utilisateur et de reporting visuel en temps réel de l’avancement ainsi que des problèmes rencontrés (affichage mural à base de post-it).
• Test driven development (TDD)
• Récit utilisateur

Source : https://fr.wikipedia.org/wiki/Scrum_(développement)

3.4. Méthode de développement Lean

Le lean software development est l’application du lean au développement logiciel pour une gestion au plus juste. Cette méthode est conceptualisée par Tom et Mary Poppendieck dans leur ouvrage Lean software development : an agile toolkit publié en 2003.

L’objectif est d’obtenir pour l’activité du développement logiciel des résultats équivalents à ceux obtenus par les diverses applications du lean (production industrielle, services, ingénierie, santé).

Le modèle, basé sur le développement itératif et les méthodes agiles met en avant sept principes :

1. Éliminer les gaspillages : comme pour le lean, le gaspillage est défini comme ce qui n’apporte pas de valeur au produit. La valeur étant définie du point de vue de l’utilisateur ;
2. Améliorer l’apprentissage ;
3. Retarder l’engagement ;
4. Livrer aussi vite que possible ;
5. Donner le pouvoir à l’équipe ;
6. Intégrer la qualité dès la conception ;
7. Considérer le produit dans sa globalité.

Source : https://fr.wikipedia.org/wiki/Lean_(production)#Lean_software_development

4. Méthodes de test

4.1. Tests d’intégration

4.2. Tests de performance

4.3. Tests de sécurité

4.4. Test-Driven Development (TDD)

Test-Driven Development (TDD), ou “Développements Pilotés par les Tests” en français, est une méthode de développement de logiciel, qui consiste à concevoir un logiciel par petits pas, de façon itérative et incrémentale, en écrivant chaque test avant d’écrire le code source et en remaniant le code continuellement.

Le processus préconisé par TDD comporte cinq étapes :

1. écrire un seul test qui décrit une partie du problème à résoudre ;
2. vérifier que le test échoue, autrement dit qu’il est valide, c’est-à-dire que le code se rapportant à ce test n’existe pas ;
3. écrire juste assez de code pour que le test réussisse ;
4. vérifier que le test passe, ainsi que les autres tests existants ;
5. puis remanier le code, c’est-à-dire l’améliorer sans en altérer le comportement.

Ce processus est répété en plusieurs cycles, jusqu’à résoudre le problème d’origine dans son intégralité. Ces cycles itératifs de développement sont appelés des micro-cycles de TDD.

Source : Processus cyclique de développement

4. Pipeline CI/CD

Qu’est-ce le déploiement continu ?

Le déploiement continu d’une application consiste à le mettre en production dès que tous les tests logiciels ont été réalisés.

Définition du déploiement continu

Le déploiement continu peut être considéré comme une extension de l’intégration continue (CI), visant à minimiser délai d’exécution, soit le temps écoulé entre le développement d’une nouvelle ligne de code et l’utilisation de ce nouveau code par les utilisateurs en production. ¹

Qu’est-ce la livraison continue (CD) ?

On confond souvent “déploiement continu” (Continuous Deployment) et “livraison continue” (Continuous Delivery).

La livraison continue est une suite de pratiques conçues pour garantir que le code peut être déployé rapidement et en toute sécurité vers la production en livrant chaque changement dans un environnement proche de la production et en garantissant que les applications et services métier fonctionnent comme prévu grâce à des tests automatisés rigoureux. Comme chaque modification est fournie à un environnement intermédiaire en utilisant une automatisation complète, vous pouvez avoir l’assurance que l’application peut être déployée en production en appuyant sur un bouton lorsque tout est prêt.

Le déploiement continu est la prochaine étape de la livraison continue : chaque modification qui passe les tests automatisés est automatiquement déployée en production. Le déploiement continu devrait être l’objectif de la plupart des entreprises qui ne sont pas limitées par des exigences réglementaires ou autres. ²

Qu’est-ce que l’intégration continue (CI) ?

Au regard des deux pratiques précédentes, on peut trouver plusieurs définitions de l’intégration continue (CI).

Définition de l’intégration continue selon Wikipedia FR

L’intégration continue repose souvent sur la mise en place d’une brique logicielle permettant l’automatisation de tâches : compilation, tests unitaires et fonctionnels, validation produit, tests de performance … À chaque changement du code, cette brique logicielle va exécuter un ensemble de tâches et produire un ensemble de résultats, que le développeur peut par la suite consulter. Cette intégration permet ainsi de ne pas oublier d’éléments lors de la mise en production et donc ainsi améliorer la qualité du produit. ³

Définition de l’intégration continue selon l’Agile Alliance

Le terme intégration fait référence aux efforts encore nécessaires, après que des programmeurs individuels ou des sous-groupes de programmeurs travaillent sur des composants séparés, pour qu’une équipe de projet fournisse un produit pouvant être livré comme un ensemble fonctionnel. ⁴

Par exemple, si deux développeurs, travaillant en parallèle, implémentent de nouvelles fonctionnalités sur deux composants A et B, chacun pense à sa satisfaction que le travail est terminé, puis vérifie que les changements à A et B sont cohérents et résout toute incohérence, appartiennent à la catégorie de l’intégration.

Les équipes pratiquant une intégration continue recherchent deux objectifs: d’une part, {==minimiser la durée et l’effort requis par chaque épisode d’intégration==} et, d’autre part, {==être en mesure de livrer une version du produit pouvant être mis à disposition à tout moment==}. En pratique, ce double objectif nécessite une procédure d’intégration reproductible à tout le moins et largement automatisée. Ceci est réalisé grâce à des outils de gestion de version, des politiques et des conventions d’équipe, et des outils spécialement conçus pour aider à réaliser une intégration continue. ⁵

Serveurs d’intégration continue (CI)

Jenkins, GitLab CI, Buildbot, Drone, Concourse sont des outils CI/CD, ⁶ mais on en trouvera beaucoup d’autres. [^Référence manquante]

5. DevOps

6. Language de programmation et plateformes