Le Behavior-Driven Development (ou BDD) est une méthode agile qui encourage la collaboration entre les développeurs, les responsables qualités, les intervenants non-techniques et les entreprises participant à un projet de logiciel. Il a été conçu en 2003 par Dan North comme une réponse au Test Driven Development.

Le processus BDD met en avant le langage naturel et les interactions dans le processus de développement logiciel.
Les développeurs utilisant le BDD utilisent un langage naturel en combinaison avec le langage du DDD (Domaine Domain Driven) Design pour décrire l'objectif et le bénéfice de leur code.

Cela permet aux développeurs de se concentrer sur les raisons pour lesquelles le code doit être créé, plutôt que les détails techniques, et minimise la traduction entre le langage technique dans lequel le code est écrit et le domaine de la langue parlée par les entreprises, les utilisateurs, les intervenants, la gestion de projet...

Les pratiques de BDD comprennent :

• La participation des parties prenantes dans le processus par le biais de l'extérieur dans le développement de logiciels outside-in software development
• L'utilisation d'exemples pour décrire le comportement de la demande, ou d'unités de code
• Automatisation de ces exemples pour fournir rapidement des commentaires et des tests de non-régression
• Dans le test logiciel, l'utilisation du mot "devrait" contribue à clarifier la responsabilité et permet la remise en cause de la fonctionnalité du logiciel
• L'utilisation de "vérifier que" permet de différencier les résultats obtenus dans le champ d'application du code en question en provenance des effets secondaires d'autres éléments du code.
• Enfin, l'utilisation de "mocks" en remplacement des modules de code qui n'ont pas encore été écrits

Le Test-Driven Development (TDD) ou en français développement piloté par les tests est une technique de développement de logiciel qui préconise d'écrire les tests unitaires avant d'écrire le code source d'un logiciel.

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

• Écrire un premier test ;
• Vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide ;
• Écrire juste le code suffisant pour passer le test ;
• Vérifier que le test passe ;
• Réusiner le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités.

Les méthodes agiles sont des groupes de pratiques de pilotage et de réalisation de projets.
Elles ont pour origine le manifeste Agile, rédigé en 2001, qui consacre le terme d'agile pour référencer de multiples méthodes existantes.

Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles, impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes.

Elles reposent sur un cycle de développement itératif, incrémental et adaptatif et doivent respecter quatre valeurs fondamentales déclinées en douze principes desquels découlent une base de pratiques, soit communes, soit complémentaires.

Scrum est un schéma d'organisation de développement de produits complexes. Il est défini par ses créateurs comme un cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible.

Scrum est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile.

Le framework s'appuie sur le découpage d'un projet en boîtes de temps, nommées sprints.

Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour 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 flot de travail de l'équipe de développement est facilité par son auto-organisation, il n'y aura donc pas de gestionnaire de projet.

Le modèle du cycle en V (par comparaison avec les méthodes dites agiles) est un modèle conceptuel de gestion de projet imaginé à la suite du problème de réactivité du modèle en cascade.

Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel.

Issu du monde de l'industrie, le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980. Depuis, avec l'apparition de l'ingénierie des systèmes, c'est devenu un standard conceptuel dans tous les domaines de l'Industrie. Le monde du logiciel ayant de fait pris un peu d'avance en termes de maturité, on trouvera souvent dans la bibliographie courante des références au monde du logiciel qui pourront s'appliquer au système.

Le modèle en spirale (spiral model) est un modèle de cycle de développement logiciel qui reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et dur. Le cycle en spirale met cependant plus l'accent sur la gestion des risques que le cycle en V.

Le modèle en spirale a été défini par Barry Boehm en 1988 dans son article "A Spiral Model of Software Development and Enhancement".