Bien programmer en langage C

Date de publication : 28 mai 2008

XII. Développement de projet informatique
XII-A. Introduction au développement d'un projet informatique
XII-B. Un peu de reflexion et du bon sens
XII-C. Le cycle en V
XII-C-1. Le document de définition
XII-C-2. Le document de conception
XII-C-3. Les fichiers sources et les tests unitaires
XII-C-4. Le cahier de test d'intégration
XII-C-5. Le document de validation
XII-C-6. Pourquoi en V ?
XII-D. Critique de la méthode du cycle en V
XII-E. Les méthodes dites 'agiles'
XII-E-1. Introduction
XII-E-1-a. Les itérations courtes
XII-E-1-b. La conception par les tests
XII-E-1-c. La réécriture
XII-E-1-d. Le travail en binôme
XII-E-1-e. Le travail en équipe

XII. Développement de projet informatique

XII-A. Introduction au développement d'un projet informatique

L'aboutissement d'un projet informatique est une opération complexe qui mobilise des moyens importants en terme de temps et de personnel, donc de budget. Si on y prend pas garde, on se retrouve facilement en dépassement de délai et de coût. de plus, une mauvaise étude peut mener à un résultat non conforme à la demande.

Il convient donc d'agir avec le plus d'efficacité possible. Pour cela, il existe un certain nombre de règles simples qui permettent de gérer le projet de façon optimale et maîtrisée.

XII-B. Un peu de reflexion et du bon sens

Il est un principe de base et de bon sens qui veut que

"ce qui se conçoit bien s'énonce clairement".

Ce principe, énoncé par un poète français du 17 ème siècle, prend tout son sens dès qu'il s'agit de réaliser le moindre projet. Il dit, en substance, que l'on ne peut réaliser quoique ce soit de sérieux si on a pas pris la peine au préalable de définir ce que l'on veut faire.

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.

XII-C. Le cycle en V

Le cycle en V est une formalisation du cycle de développement mettant en oeuvre 5 étapes :

Définition
Conception
Réalisation
Intégration
Validation

Chaque étape est matérialisée par un document :

Le document de définition
Le document de conception
Les fichiers sources et les tests unitaires
Le cahier de tests d'intégration
Le document de validation

XII-C-1. Le document de définition

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.

XII-C-2. Le document de conception

Ce document décrit noir sur blanc les moyens mis en oeuvre 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

XII-C-3. Les fichiers sources et les tests unitaires

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. Si 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

XII-C-4. Le cahier de test d'intégration

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

XII-C-5. Le document de validation

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.

XII-C-6. Pourquoi en V ?

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

XII-D. Critique de la méthode du cycle en V

Théoriquement, la méthode en V est parfaite. Elle décrit un processus bien huilé qui transforme l'idée du client en produit fini.

Dans la pratique, l'expérience montre que, loi de Murphy aidant, rien ne se passe comme prévu !

De nombreux facteurs s'acharnent à faire dériver le projet, que ce soit en matière de coût et de délai, mais aussi, par exemple, en terme de faisabilité de telle ou telle fonctionnalité ou d'erreur de conception grave (mauvais choix technologique, par exemple).

Tout le problème est donc de trouver le moyen d'identifier rapidement les obstacles et autres points bloquants. Il existe pour ça des méthodes dites 'agiles' qui permettent d'obtenir des résultats bien meilleurs que la méthode en V classique appliquée brutalement.

Ceci dit, les principes de la méthode en V sont bons, mais ils ne doivent pas être appliqués directement à la réalisation de gros projets, mais sont utilisés d'une manière simplifiée mais rigoureuse pour la réalisation des itérations courtes telles que les recommandent les méthodes dites 'agiles'.

XII-E. Les méthodes dites 'agiles'

XII-E-1. Introduction

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

XII-E-1-a. Les itérations courtes

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 1 ou 2 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éalistion sont moindres).

XII-E-1-b. La conception par les tests

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 le conception :

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

XII-E-1-c. La réécriture

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).

XII-E-1-d. Le travail en binôme

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.

XII-E-1-e. Le travail en équipe

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çons à ce que la connaissance soit partagée. C'est très utile en cas de défaillance d'un des équipier(s ?) 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 (©).

Précédent Sommaire Suivant

Copyright © 2008 Emmanuel Delahaye. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.