Programmation Cycle en V
Le cycle en V est une amélioration du processus en cascade. Les étapes sont :
Le cycle en V tire son nom de la mise en correspondance de ces différentes étapes. Si on démarre le V par « Étude », on termine le V par « Recettage » : ces deux étapes se correspondent, elles sont au même niveau du cycle en V. On voit alors de proche en proche, en suivant les 3 niveaux « horizontaux » sous-jacents, le dernier niveau étant la pointe du V, avec le codage pour seule étape, les niveaux intermédiaires faisant correspondre fort logiquement les niveaux de détail, à savoir qu'une fonction faisant l'objet d'une conception détaillée (branche de gauche), elle fera l'objet d'un test unitaire (branche de droite). De même, un sous-système fonctionnel faisant l'objet d'une conception générale, il faudra prévoir un jeu de tests d'intégration pour lui.
C'est d'ailleurs là l'intérêt du cycle en V ; ce n'est pas tant de fournir un outil mnémotechnique permettant de ne pas oublier une étape, ni même une méthode d'analyse (branche de gauche) et de synthèse (branche de droite). Non, le cycle en V a surtout une vocation pédagogique : il souligne qu'à chaque étape en amont du codage (branche analyse), il faut « ouvrir » un dossier pour l'étape en aval correspondante( branche synthèse). Par exemple, on demandera des scénarios de recette avant de commencer toute conception. Cela est non seulement une bonne préparation de la recette, mais aussi un moyen d'alimenter l'analyse.
D'un point de vue technique, le cycle en V permet de limiter le "scope" de validation de chaque étape, en ne regardant la conformité de celle-ci « que » par rapport à la précédente sur le V. Bien entendu, on peut avoir « en cascade » justement, des reprises à faire dans l'étape précédente. On fera alors attention de répercuter cela d'abord sur les étapes précédentes (de bas en haut), puis, de haut en bas, sur les étapes correspondantes dans la branche de droite, et enfin, vérifier de bas en haut la compatibilité des changements avec le reste de l'avancement des travaux.
L'énorme intérêt du cycle en V est qu'il est un excellent support à la formalisation des relations entre le client et l'équipe de développement. Il oblige le client à réfléchir aux différents aspects de sa demande. La phase de spécification permet à l'équipe de développement de vérifier qu'elle a bien compris la demande du client. En effet, le client valide généralement la spécification. Tel que présenté, le cycle en V ne permet de lever les interrogations technologiques tard. On ajoute souvent en parallèle de la phase de spécification, une phase de validation technologique afin de lever les écueils techniques (performance, difficulté algorithmique spécifique, ...). Dans le cas d'un développement web ou d'une interface graphique, la spécification est accompagnée d'une maquette graphique.
Bien que les valeurs puissent varier d'un développement à l'autre et d'un domaine à l'autre (web et aéronautique par exemple), on peut estimer couramment les phases de spécification et de conception chacune à 15% du temps nécessaire pour le codage dans le cas d'un développement non critique.
Le plus grand danger que présente le cycle en V est de se voir appliquer « à la lettre » dans la vraie vie. Le cycle en V n'est applicable que dans un monde de logique pure, où des assertions détaillent d'autres assertions sans écart de « sens » possible, où les opinions ne varient pas dans le temps, bref, un monde sans humanité.
On pourra pourtant en retenir de nombreux aspects : la responsabilisation du client passe par l'établissement d'un contrat. Lui faire comprendre que ses demandes en amont du projet l'engagent « fortement » pour toute la durée de celui-ci, c'est possible en se basant sur le cycle en V.
Bien comprendre le cycle en V, son apport et ses défauts, est nécessaire avant d'aborder les autres schémas de développement/réalisation/maintenance informatique.
De nombreuses normes et méthodes le supportent : ISO 9001, MIL-STD498, GAM T17, Do 178 B ; SADT, SART, OMT.
Ses inconvénients ? Il implique une grande confiance, avant de voir un premier résultat. Il ne supporte pas la forme de pensée traditionnelle, qui n'est pas si séquencée que cela.
Le cycle en V, très critiqué dans son application, est une base pédagogique très importante. Ses concepts de bases se retrouvent dans tous les autres cycles de développement.

Programmation XP
Programmation UML
UML (Unified Modeling Language) est une notation graphique pour la modélisation et la spécification de systèmes.
Elle est principalement utilisée dans la conception de logiciels mais peut être utilisée pour spécifier le fonctionnement de tout système.
La modélisation permet de concevoir des systèmes complexes à travers divers diagrammes standardisés.
Chaque diagramme spécifie différents aspects du système : architecture statiques, évolution dynamique, ...
Utiliser tous les diagrammes n'est pas nécessaire, seuls les diagrammes les plus pertinents à la conception sont obligatoires.
Ce livre présente les différents diagrammes UML afin de les comprendre, de connaître leur rôle et de pouvoir les concevoir pour la spécification de systèmes.

Programmation UML/Introduction
Prélude.
UML est un langage de modélisation qui fut conçu à l'origine comme une unification des notations des méthodes OMT (Object Modelling Technique), Booch (OOD/OOA) et OOSE.
Le principe est de démarrer l'analyse avec les diagrammes simples et grossiers, puis de les affiner en plus complexes.
Voici les différents diagrammes disponibles en UML 2.0 sous la forme d'un diagramme de classes :
Les 14 diagrammes UML 2.2 sont dépendants hiérarchiquement et se complètent, de façon à permettre la modélisation d'un projet tout au long de son cycle de vie.

Programmation OMT
Il s'agit dans la programmation OMT de regrouper, suivant trois axes, l'analyse fonctionnelle, l'analyse de classes et l'analyse dynamique (comportement du système).

Programmation impérative
Programmation/Programmation orientée objet

La programmation orientée objet ou POO existe depuis les années 1960.

Programmation orientée aspect
Programmation/Programmation par contrat
La programmation par contrat est un paradigme de programmation dans lequel le déroulement des traitements est garanti par des vérifications sur les données, ce qui permet d'être sûr que les traitements ne vont pas déclencher d'erreur. Il y a trois catégories de vérification :
Le seul langage de programmation qui implémente ce paradigme est le langage , mais des modules existent pour d'autres langages, comme JContractor pour Programmation Java.

Programmation orientée aspect/Introduction

La programmation orientée aspect cherche à séparer syntaxiquement les différentes fonctionnalités d'une application dans des aspects. Idéalement, chaque aspect traite un ensemble cohérent de fonctionnalités.
La programmation orientée aspect est notamment apparue en réaction au problème de la décomposition dominante, qui se produit en Programmation orientée objet.