Développement d'un projet informatique

Transcription

1 Développement d'un projet informatique par Emmanuel Delahaye (Espace personnel d'emmanuel Delahaye) Date de publication : 27 janvier 2008 Dernière mise à jour : 25 avril 2009 Cet article présente un certain nombre de règles simples qui permettent de gérer un projet informatique de façon optimale et maîtrisée. Votre avis et vos suggestions sur cet article nous intéressent! Alors après votre lecture, n'hésitez pas :

2 I - Introduction...3 II - Un peu de reflexion et du bon sens...4 II-A - Définition...4 II-B - Analyse descendante...4 II-C - Construction montante...4 II-D - Vérification...4 III - Cycle en V... 6 III-A - Le document de définition... 6 III-B - Le document de conception... 6 III-C - Les fichiers sources et les tests unitaires... 6 III-D - Le cahier de test d'intégration... 7 III-E - Le document de validation...7 III-F - Pourquoi en V?... 7 IV - Critique de la méthode du cycle en V... 8 V - Méthodes dites 'agiles'... 9 V-A - Introduction... 9 V-B - Les itérations courtes... 9 V-C - La conception par les tests...9 V-D - La réécriture... 9 V-E - Le travail en binôme...10 V-F - Le travail en équipe

3 I - Introduction 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

4 II - Un peu de reflexion et du bon sens... Le bon sens est la chose la mieux partagée au monde 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 (Nicolas Boileau), 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. On peut y adjoindre les 4 préceptes du Discours de la Méthode de Descartes : Ainsi, au lieu de ce grand nombre de préceptes dont la logique est composée, je crus que j'aurais assez des quatre suivants, pourvu que je prisse une ferme et constante résolution de ne manquer pas une seule fois à les observer. II-A - Définition 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. II-B - Analyse descendante 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. II-C - Construction montante 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. II-D - Vérification 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 - 4 -

5 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

6 III - 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 III-A - 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. III-B - 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 III-C - 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 (lire l'article Concevoir et réaliser un composant logiciel en C). Si il a des sorties, celles-ci sont le plus souvent - 6 -

7 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 III-D - 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 III-E - 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. III-F - 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 - 7 -

8 IV - 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'

9 V - Méthodes dites 'agiles' V-A - 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 V-B - 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). V-C - 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 : 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 V-D - 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)

10 V-E - 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. V-F - 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 é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 ( ). Plus d'informations sur les méthodes agiles : Cours sur les Méthodes Agiles