Développement d'un projet informatique

Le premier était de ne recevoir jamais aucune chose pour vraie, que je ne la connusse évidemment être telle : c'est-à-dire, d'éviter soigneusement la précipitation et la prévention ; et de ne comprendre rien de plus en mes jugements, que ce qui se présenterait si clairement et si distinctement à mon esprit, que je n'eusse aucune occasion de le mettre en doute.

Le deuxième, de diviser chacune des difficultés que j'examinerais, en autant de parcelles qu'il se pourrait, et qu'il serait requis pour les résoudre.

Le troisième, de conduire par ordre mes pensées, en commençant par les objets les plus simples et les plus aisés à connaître, pour monter peu, comme par degrés, jusques à la connaissance des plus composés ; et supposant même l'ordre entre ceux qui ne se précèdent point naturellement les uns les autres.

Et le dernier, de faire partout des dénombrements si entiers, et des revues si générales, que je fusse assuré de ne rien omettre.
Ces longues chaînes de raisons, toutes simples et faciles, dont les géomètres ont coutume de se servir, pour parvenir à leurs plus difficiles démonstrations, m'avaient donné occasion de m'imaginer que toutes les choses, qui peuvent tomber sous la connaissance des hommes, s'entre-suivent en même façon et que, pourvu seulement qu'on s'abstienne d'en recevoir aucune pour vraie qui ne le soit, et qu'on garde toujours l'ordre qu'il faut pour les déduire les unes des autres, il n'y en peut avoir de si éloignées auxquelles enfin on ne parvienne, ni de si cachées qu'on ne découvre.

Qui se résument en :

Ne recevoir aucune chose pour vraie tant que son esprit ne l'aura clairement et distinctement assimilé préalablement
Trier ses difficultés afin de mieux les examiner et les résoudre
Établir un ordre de pensées, en commençant par les plus simples jusqu'aux plus complexes et diverses, et ainsi de les retenir toutes et en ordre
Passer toutes les choses en revue afin de ne rien omettre

Cette définition préalable (ou plus simplement « Définition ») prend différents noms selon les métiers :

• objectifs ;
• cahier des charges ;
• spécifications ;
• document de définition.

Une fois que ce document est écrit, on va pouvoir concevoir le produit, c'est-à-dire trouver les moyens de réaliser les objectifs décrits dans la définition. On passe alors en phase d'analyse, ce qui se traduit par le découpage du produit en unités de plus en plus petites selon une sorte d'arborescence.

Les petits éléments deviennent alors des sortes de briques qu'il suffit de réaliser puis d'assembler pour réaliser le projet.

Ce document décrit noir sur blanc le produit attendu en termes de :

• environnement ;
• interfaces ;
• comportement ;
• performances ;
• coûts et délais.

Il répond à la question « Quoi ? »

Ce document est connu du client et signé par celui-ci.

Ce document décrit noir sur blanc les moyens mis en œuvre pour réaliser le produit :

• découpage arborescent en blocs fonctionnels ;
• architecture logicielle ;
• comportement détaillé (algorithmes, machines à états) ;
• fonctions (interfaces et comportement).

Il répond à la question « Comment ? »

Sauf indication contraire, ce document est interne.

C'est le résultat du codage des fonctions. L'organisation du source ainsi que les interfaces des fonctions publiques (points d'entrées) découlent de l'analyse résultant de la conception. Chaque bloc fonctionnel terminal (feuille de l'arbre) est testé unitairement. Il est conçu pour être autonome, par exemple sous la forme d'un composant logiciel (lire l'article Concevoir et réaliser un composant logiciel en C). S’il a des sorties, celles-ci sont le plus souvent réalisées sous forme d'appels à des fonctions externes via un pointeur de fonction, ce qui autorise les tests unitaires sans connaître les détails de l'application.

Sauf indication contraire, ces documents sont internes.

L'intégration consiste à rassembler les composants logiciels dans le but de réaliser le produit final. Une liste de tests extrêmement poussés permet de valider la conception en fonctionnement normal, aux limites et au-delà. L'ensemble de ces tests et leurs résultats sont consignés dans le cahier de test d'intégration. C'est ici que se fait la mise au point du produit. Si un composant logiciel doit être corrigé (modifications de spécifications détaillées), le test unitaire est repassé (éventuellement complété) afin de s'assurer qu'il n'y a pas de régression et que le nouvel objectif est bien atteint.

Sauf indication contraire, ce document est interne.

Le document de validation est une liste de tests 'boite noire' (c'est-à-dire que la conception est ignorée) tendant à prouver la conformité du produit avec la demande du client. Il s'appuie bien sûr sur le document de définition. On parle aussi de cahier de recette. Le fournisseur s'engage à réaliser les tests mentionnés et à en indiquer les résultats. Il signe le document. C'est en quelque sorte la garantie constructeur. En cas de litige, le client peut exiger qu'un test réputé réussi ou présentant des résultats connus, soit repassé devant lui à des fins de vérification.

Ce document est connu du client et signé par le fournisseur et par le client.

Le terme « en V » est issu de la mise en regard de chaque document et de leur portée :

• la validation est en regard de la spécification ;
• l'intégration est en regard de la conception ;
• la spécification et la validation sont du domaine du client.

Il en résulte le schéma suivant :

1 - Définition       Validation - 5
         \               /               Domaine Client/Fournisseur
------------------------------------------------------------------
           \           /                Domaine Fournisseur
  2 - Conception Intégration - 4
             \       /
        3 - Codage et TU

Les méthodes agiles sont basées sur l'expérience et le bon sens. Plusieurs idées maîtresses régissent ces méthodes. Elles visent avant tout à obtenir un résultat, et non à appliquer un formalisme rigide. La méthode est centrée sur le produit. Elle n'est qu'un outil au service de la réalisation et non une fin en soi.

Les principales caractéristiques sont :

• les itérations courtes ;
• la conception par les tests ;
• la réécriture ;
• le travail en binôme ;
• le travail en équipe.

C'est le point fort qui fait la différence avec les méthodes traditionnelles. Il s'agit, à partir des spécifications générales, de définir rapidement un projet aux fonctionnalités minimales, mais essentielles et surtout centrées sur les aspects innovants (vu du réalisateur), de façon à montrer rapidement la faisabilité du projet (maquettage). Cela permet très rapidement (en quelques semaines) de savoir si le projet est viable ou non.

Le Chef de Projet (CP) fixe des objectifs précis avec des délais réalistes et un point d'avancement est fait chaque semaine. Si une dérive ou un point bloquant est constaté, les compétences nécessaires sont mises à disposition pour résoudre le problème (si c'est possible). On peut très bien tomber sur un échec. Mais il vaut mieux le savoir au bout de trois semaines qu'au bout de trois ans (des boites ont coulé pour moins que ça…)

D'autre part, c'est l'occasion de tester la spécification et de demander au client des précisions sur les points qui auraient échappé à la rédaction du cahier des charges. Là encore, il vaut mieux demander les précisions au début du projet qu'au bout de un ou deux ans. Question de crédibilité…

Dès qu'une itération est terminée (et même avant), le CP planifie l'itération suivante selon les mêmes critères. On commence par le plus difficile (ou le moins connu), et on laisse le code routinier pour la fin. (Les risques de tomber sur des problèmes de conception et/ou de réalisation sont moindres).

Ce principe s'applique à la réalisation d'une fonction ou d'un groupe de fonction (classe gérant un objet, par exemple). Il est admis que lorsque l'on réalise du code, celui-ci doit être testé unitairement. Les méthodes agiles proposent d'aller plus loin en intégrant le test dans la conception :

1. rédaction de la spécification détaillée ;
2. rédaction des tests permettant de vérifier l'interface et le comportement nominal, aux limites, hors limites ;
3. codage de l'environnement de test selon des méthodes simples et éprouvées (plus ou moins automatisées) ;
4. codage des tests avec un emplacement pour le DUT (Device Under Test). L'appel doit se faire dans les conditions d'une application ;
5. codage de la ou des fonctions dans des modules séparés, évidemment.

Le code n'est pas immuable. Plutôt que de le corriger à l'infini, il vaut mieux parfois admettre qu'il faut réécrire une portion de code (refactoring).

Quand c'est possible, il est souhaitable que le codage se fasse en binôme. L'un tient le clavier et ne fait que taper le code. L'autre tient le document de spécification, guide le codeur dans les grandes lignes et vérifie ce qui est tapé (conformité au langage, etc.) C'est comme ça qu'on élimine les problèmes de comportement indéfini.

Quand c'est possible, il est souhaitable que l'équipe ne se spécialise pas dans tel ou tel domaine du projet et qu'il y ait des rotations de façon à ce que la connaissance soit partagée. C'est très utile en cas de défaillance d'un des équipiers et chacun est obligé d'avoir le même niveau de compétence que son voisin et inversement. Le niveau général augmente, ce qui est une Bonne Chose (©).