Gestion de projet Cycles de production Laurent Berenguier – laurent.berenguier@gmail.com Patrick Reynoudt – patrick.reynoudt@gmail.com

Des étapes clés Cycle de développement Analyse Capturer et décrire précisément le besoin Identifier le périmètre fonctionnelle et les contraintes non fonctionnelles Conception Construire une solution possible répondant au besoin Développement Réaliser la solution dans le respect de la conception (et donc de la spécification) Validation Vérifier que le logiciel produit répond au besoin exprimé Compléments pour le cycle de vie du logiciel Déploiement Intégrer le logiciel dans son environnement cible Le rendre prêt à l’emploi Maintenance Modifier le logiciel pour suivre l’évolution de son environnement (organisation, technique…) et répondre aux nouveaux besoins Il existe plusieurs types de maintenance : perfective, préventive, corrective, évolutive

Cycle de vie du logiciel (1/2) La formalisation d’un cycle de vie doit permettre de Définir clairement les étapes retenues dans le cadre du projet Donner pour chacune des étapes Les données en entrée Une méthodologie de réalisation Les critères de sortie Les acteurs impliqués Obtenir des produits fiables, de qualité constante Maîtriser la complexité croissante des projets Accepter l’évolution des besoins et les omissions client Un cycle est un modèle global donnant l’organisation de ces différentes étapes Il nous aide à comprendre les différentes étapes et décrit les relations inter-étapes Il doit être instancié pour chaque projet selon ses spécificités Le travail sur le cycle de production a pour but d’optimiser les coûts et les risques engendrés par le projet

Cycle de vie du logiciel (2/2) Le choix d’un modèle est un élément clé dès le début d’un projet Chaque cycle / modèle de production présente des avantages et des inconvénients qu’il faut prendre en compte L’instanciation d’un modèle doit être faite selon les spécificités du projet Quelques cycles « de base » Cascade V Incrémental Prototypage Exploratoire eXtrem Programming

Cycle en cascade (1/2) Spécification du logiciel Cahier des charges Spécifications fonctionnelles Conception préliminaire Dossier d’analyse Conception détaillée Dossier de conception Modèle d’architecture Codage Code documenté Tests unitaires Rapports de test Intégration et validation Rapports de test Documentation utilisateur Exploitation

Cycle en cascade (2/2) Avantages Inconvénients Premier cycle construit comme un processus Définition fonctionnelle Terminologie précise et activités bien identifiées Les livrables sont clairs en sortie de chaque étape et de fait, les entrées sont claires pour l’étape suivante Inconvénients Cycle très rigide : les étapes sont verrouillées L’activité informatique est-elle compatible avec une vue séquentielle? Pour le client, les premiers résultats visibles sont tardifs Qu’en est-il de la faisabilité du logiciel ?

Cycle en V (1/2) Demandes client Système validé Validation du système Plan de validation Validation du système Étude des besoins Spécification des besoins Plan de vérification Tests fonctionnels Conception générale Dossier d’intégration Tests d’intégration Conception détaillée Dossiers de test Tests unitaires Codage Gestion de la documentation et de la configuration Gestion du projet

Cycle en V (2/2) Avantages Inconvénients La remontée du cycle est bien verrouillée par des plans et des livrables Convient bien à des grands projets La gestion de projets est signalée, même si le schéma n’exprime pas le jalonnement La notion d’intégration et de plan d’intégration figure clairement A chaque étape du développement correspond une phase de validation Inconvénients L’élément de base reste une cascade

Cycle de vie incrémental (1/2) Système cœur Spécification du logiciel Conception préliminaire Incrément 1 Conception détaillée Spécification du logiciel Codage Tests unitaires Conception préliminaire Conception détaillée Incrément 2 Spécification du logiciel Codage Intégration et validation Tests unitaires Conception préliminaire Conception détaillée Codage Tests unitaires

Cycle de vie incrémental (2/2) Avantages Souplesse, absence de blocage en cas de spécification incomplète Une première approche vis-à-vis de la complexité Les lots sont des réalisations à taille humaine, pouvant être traités par des équipes très réduites Les développeurs peuvent viser des objectifs à court terme Le client peut voir rapidement des réalisations Inconvénients Le cycle ne dit pas comment les lots fonctionnels sont découpés, la difficulté est d’identifier le système cœur et les incréments Le découpage ne résout pas l’aspect séquentiel et rigide type Cascade sur chacun des lots Accroissement des coûts  Difficultés de gestion de projet, de la configuration, de la qualité

Cycle par prototypage (1/2) « Grandes lignes » des besoins Construction du prototype Évaluation avec le client ? Mise à jour des spécifications KO OK Spécifications

Cycle par prototypage (2/2) Avantages Une application informatique est un excellent support de communication avec le Client Par l’utilisation de technologies adéquates, le temps de prototypage peut être très court On peut tirer du prototype d’autres enseignements : réflexion sur l’architecture et/ou une faisabilité technique, clarification des besoins, essai des IHM Inconvénients Le Client peut voir dans le prototype le système final (et donc être insatisfait des imperfections) La technologie employée spécialement par le prototype donne une idée qui peut être fausse du développement futur Il faut avoir la détermination de jeter le prototype et le prototype ne doit implémenter que les parties qui nécessitent une réflexion

Cycle de vie exploratoire (1/2) « Résumé » des spécifications Construction du système Utilisation du système Convient ? Non Oui Livrer le système

Cycle de vie exploratoire (2/2) Avantages Convient pour des domaines où la spécification est réellement impossible à obtenir Inconvénients Pas de gestion de projet, plannings très difficiles à obtenir Rien de contractuel : que signifie le mot ‘convient’ s’il n’y a pas de cahier des charges en entrée Itérations nombreuses : documentation difficile à gérer  Nécessite des outils avancés de développement rapide pour atteindre une certaine efficacité

Cycle de vie eXtrem Programming – XP (1/3) Scénarios utilisateurs Scénarios de test Spécifications Nouveau scénario utilisateur Bugs Métaphore du système Planification release Plan de livraison Dernière version Tests d’acceptance Itération Approbation client Transition architecturale Prochaine itération Estimations confiantes Estimations incertaines Transition

Cycle de vie eXtrem Programming – XP (2/3) eXtrem Programming fait partie des nouvelles méthodes dites agiles de gestion de projet informatique Il s’appuie donc sur leurs 4 Valeurs Essentielles Communication Tout doit être prétexte à communiquer. Privilégier les échanges en face-à-face. Simplicité Faire simple avant tout Retour d’information (feedback) Utiliser les expériences passées et les remarques du client le plus possible Courage Il faudra peut-être jeter des semaines de travail pour suivre de nouvelles exigences client et faire face à une difficulté

Cycle de vie eXtrem Programming – XP (3/3) Les 13 pratiques de l’eXtrem Programming Client sur le Site Pour une meilleure communication, le client et les développeurs travaillent dans le même espace. Séance de Planification Le client définit les scénarios utilisateurs prioritaires. L’équipe discute le contenu de ces scénarios, définit les tâches techniques sous-jacentes et les estime ces tâches. Intégration Continue Le système est intégralement assemblé et testé une à plusieurs fois par jour. Livraisons Fréquentes Le rythme des livraisons est de l'ordre de quelques semaines. Rythme Soutenable L'équipe ne fait pas d'heures supplémentaires deux semaines de suite. Tests de Recette Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client. Tests Unitaires Tests automatisés écrits pour chaque méthode. Ces tests doivent passer à 100% continuellement. Conception Simple Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité. Métaphore Une analogie utilisée comme modèle conceptuel du système en cours de développement. Remaniement Continu Modification du code par laquelle on améliore sa conception sans en modifier le comportement. Convention de Code Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe. Programmation En Binôme Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet. Propriété Collective du Code Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

Conclusion Les cycles vie sont nombreux et différents Ils évoluent continuellement, de manière théorique et/ou pratique, avec l’évolution des projets informatiques Il convient d’adapter le choix en fonction des spécificités du projet telles que la taille, la criticité, la maturité, l’environnement, …