Genielogiciel

Génie logiciel Méthodes de conduite de projet Tester, optimiser, structurer ses applications Jean David Olekhnovitch jd@olek.fr - www.olek.fr Support sous Licence Creative Commons Certains schémas sont issus de Wikipedia - www.wikipedia.org

Prologue : The Mythical Man Month • Livre écrit en 1975 • Témoignage sur l’expérience d’un projet s’engluant dans la complexité • Les conclusions sont un peu datées, mais les problèmes soulevés restent très actuels

Loi de Brooks • “Ajouter des ressources humaines à un projet en retard ne fait qu’accentuer ce retard” • Ces personnes doivent prendre le temps de se former au projet • Complexité des communications

L’effet “deuxième système” • Un informaticien n’ayant pas eu le temps d’inclure certaines fonctions dans un premier système va vouloir les inclure dans le second • Point de salut sans renoncement

L’unité conceptuelle • Préserver l’unité de la conception d’un projet en séparant son architecture de son implémentation • Accepter de rejeter une super idée si elle ne s’intègre pas vraiment au projet • On doit pouvoir décider qu’un programme possède moins de fonctions que possible

Le prototype • Toute nouvelle orientation technique est précédée d’un prototype • Sert à la conception du programme avec un certain “recul” • A pour vocation d’être jetable • Ne doit pas être livré au client

Documents de base • Rédigés par l’architecte du projet • Quels sont les objectifs • Comment les atteindre • Qui est responsable de quoi • Quand doivent ils être atteints • Combien chacun coûtera • Doivent révéler les incohérences d’un projet

Planiﬁcation • Se souvenir du coût d’une tâche • Certaines tâches sont bien plus coûteuses que d’autres, techniquement parlant • Ex : concevoir un compilateur est 3 fois plus coûteux que concevoir une application classique

Le “chirurgien en chef” • En chirurgie, toute opération est hiérarchisée par les compétences de chacun • Un chirurgien en chef s’occupe des tâches essentielles et dirige son équipe • L’équipe l’appuie et s’occupe des tâches moins essentielles • Tenir compte des capacités de chacun

L’âge de glace • Chaque projet doit gérer des périodes de “gel”, caractérisés par des deadlines officielles : • Gel des spécifications, afin de pouvoir lancer un cycle de développement • Gel du développement, afin de pouvoir finaliser une version (debug)

Outils sur commande • Plutôt que chacun développe ses outils dans son coin • Inclure une personne dans le projet qui sera dédié à cette tâche • Mutualisera les besoins • Centralisera les développements et fournitures d’outils

Prologue-bis : les lois de Murphy • Une chose n’est jamais aussi simple qu’elle n’en a l’air • Tout prend plus de temps que vous le pensiez • S’il y a plus d’une façon de faire les choses, et que l’une d’elle aboutit à un désastre, alors quelqu’un procédera ainsi • Corrolaire de Finagle : Tout ce qui peut aller mal, ira mal

Encore pire • Cercle vicieux de Carvey : • La Loi de Murphy se vériﬁe toujours... sauf lorsqu’on cherche à la vériﬁer • Loi de Paquel : • La caractéristique la plus constante de l’informatique est la capacité des utilisateurs à saturer tout système mis à disposition

Industrialisation ? • Faut il industrialiser le développement logiciel ? • Utilisé ici par opposition à “artisanal” • Taylorisme, etc... • Analyser l’action de production dans le but de l’améliorer • Normalisation des outils et composants

Artisanat ? • Succès d’un projet encore essentiellement lié à la compétence de ses acteurs • Fabrication sur mesure • Difﬁcile de reproduire une démarche d’un projet à l’autre • Technologies récentes, en pleine évolution

Normalisation et rationalisation • Cette transition de l’artisanat à “l’industrie” logicielle passe par différents efforts • En automatisant des tâches • En utilisant des normalisations • En rationalisant la création

Cycles de développement Ordonnancer son projet

Cycles de développement • L’informatique intervient dans des domaines de plus en plus complexes • Dès les années 50/60, on a commencé a théoriser sur les méthodes de conduites de projet • Grande question : dans quel ordre procéder ? • Théories sur les cycles

En cascade

En cascade • Directement hérité des méthodes utilisées dans les conceptions “en dur” • Bâtiment... • Simple bon sens : on ne peut faire les choses que dans l’ordre • Le toit se fait après les fondations

En cascade • Adapté à un processus logiciel ? • Oui : • Forcer à faire les choses dans l’ordre implique une certaine discipline • Non : • Le logiciel, immatériel par déﬁnition, permet des organisations plus souples

Cycle en V

Cycle en V • Méthode classique de “feedback” de projet : • Chaque étape fait écho à une étape précédente • Ex : les tests se réfèrent aux spéciﬁcations • ...et vice versa • Adapté lorsqu’un projet nécessite une certaine montée en puissance

Cycle en V • Plus le “V” descend profond, plus les erreurs de conceptions peuvent être importantes • Et le temps perdu important • Une certaine “autocritique” permettant de s’améliorer au ﬁl du temps • Sans forcément en faire bénéﬁcier le projet en cours

Cycles en spirales • Il s’agit simplement de cycles découpés en plusieurs “V” • Permet de prendre en compte la notion de “releases” successives et de plus en plus complètes/complexes • Le cycle dit «en W» est une toute petite spirale ;)

Cycle itératif • Objectif : livrer quelque chose d’incomplet, mais au plus vite • Apprendre par l’erreur • Doit accompagner des méthodes dites “agiles”

Cycle itératif

Cycle itératif • Nécessite une grande réactivité de la part du “client” • Bien adapté dans le cadre de projets “glissants” au niveau fonctionnel • De moins en moins adapté lorsque les équipes sont très importantes

RUP (Rational) Uniﬁed Process La première méthode liée aux concepts objets

Méthode liée à UML : RUP • Rational Uniﬁed Process • Suite des travaux des ‘three amigos’ • Méthode vendue par Rational • Particulièrement adapté à UML et au développement objet

Utilisation de RUP • Conçu dans le cadre de projets énormes • Gestion commerciale Ericsson • Très (trop) lourd pour des projets moyens • Mais peut s’adapter • Abord difﬁcile car vocabulaire dense • Mais méthode validée à de nombreuses occasions

4 P du développement objet • Personnes • Rôle joué par les acteurs d’une problématique • Projet • Le projet fait le produit • Produit • Un système logiciel • Processus • Dirige les projets

Fondement de RUP • RUP est : • Piloté par les cas d’utilisation • Centré sur l’architecture • Itératif et incrémental

Modélisation par les use cases • Notion introduite par Ivar Jacobson • Permetdu cahier des charges à une : comment passer de répondre à la question représentation rationnelle ?

Processus et cas d’utilisation • Le processus est piloté par les cas d’utilisations déﬁnis dans la première phase d’analyse • Permet d’appréhender les besoins • Dirige le processus tout au long de la vie du projet • Support de l’architecture logicielle

Les Use Cases • Analyse Fonctionnelle basée sur la notions d’acteurs • Compréhensibles à la fois par les développeurs et le client • Doit permettre de recenser la totalité des détails à traiter d’un problème

Quand exploiter les use cases ? • Les uses cases sont détaillés lors de l’analyse • Puis spéciﬁés en terme informatique • Réalisés par la conception • Concrètement implémentés par les développeurs • Vériﬁés par les scénarios de tests

Notion d’acteur • Entité externe (être humain, mécanisme matériel, autre programme…) • Doit interagir avec le système à mettre en place • Préférer la notion d’acteur logique à celle d’acteur physique

Différents acteurs • Acteur ‘humain’ : le stick man • Acteur système : rectangle • Acteur principal : agit directement sur le système • Acteur secondaire : sollicité par le système pour obtenir des données

Exemple de use case

Exemple plus complet

Description textuelle • Un use case efficace est complété d’une fiche signalétique • Résumé d’identification • Description des enchaînements • Autres renseignements (projets d’interface, liste de contraintes…)

Relations entre cas • Déclenche : entre un acteur principal et un cas d’utilisation • Utilise (include) : entre deux cas • obligatoire • Etend (extends) : entre deux cas • Impératif • Généralisation Héritage

Packages de use cases • Permet de simpliﬁer des schémas de use cases • Utile dans le cas d’implémentation d’application métier

Notion d’architecture • Au sens de RUP, une architecture : • Sert à comprendre le système lorsqu’il est complexe • Pilote le projet en découpant les tâches • Favorise la réutilisation

Architecture • Fait le lien entre l’analyse et l’implémentation physique • Maîtrise technique • Elements structuraux • Effectué en parallèle avec l’analyse, avec un petit décalage

Notion d’artefact • Un artefact est un élément produit ou modiﬁé dans le cadre d’un processus de développement • Ca peut être un document, un diagramme, un compte rendu de réunion... • ...mais aussi un code source, un écran, une base de données...

Notion de rôle • Ensemble d’activités et de responsabilités • Analystes • Développeurs • Testeurs • Managers

Notion de discipline • Une discipline est un agrégat d’activités, associé à : • Des artefacts • Un workﬂow (UML) • Il existe 6 disciplines d’ingénierie (voir cycles page suivante), et 3 disciplines de support (Project, Conﬁguration, Environment)

Enchaînements d’activité • Expression des besoins • Use cases • Analyse • Refonte par l’informaticien des use cases • Conception • Architecture et modélisation • Implémentation • Tests

Gestion de projets par itération • Cycle complet : • Business Modeling • Requirements • Analysis and design • Implementations • Test • Deployement • Chaque itération ne contient pas forcément toutes les phases !

Phases d’un développement

Business Modeling • Définir un modèle d’organisation • Identifier les acteurs • Identifier les processus métier, la vision métier • Etape pouvant être négligée si les processus métiers sont déjà parfaitement maîtrisés

Artefacts d’un business modeling • Business Glossary : recensement des termes métiers utilisés, permettant d’avoir un vocabulaire commun • Business Use Case Model : première version des use cases visant essentiellement a déterminer les acteurs et un premier découpage sommaire des cas d’utilisation

Gestion des exigences (requirements) • On passe ici des déﬁnitions métier aux exigences du projet • Rôle essentiel du client, puisque c’est ici qu’il donne ses exigences et recommandations

Artefact des requirements • Glossary : termes utilisés dans le projet • Business Case & Vision : Recensement des arguments sur l’intéret du projet (dont le retour sur investissement, ROI) • Risk List : Ensemble des risques identiﬁés et associés au projet • User Interface Prototype : première version de l’interface graphique (ex: maquette HTML)

Analyse et conception • Objectif principal : traduire les cas d’utilisation en artefacts de conception du système • On tient compte de l’environnement d’implémentation • Va permettre de piloter la conception de l’architecture

Artefacts Analysis & Design • Software architecture : description formelle de l’architecture du système • Design & deployment model : répartition physique des composants • Data model : structure logique et physique de la base de données

Implémentation • On afﬁne ici le modèle de conception d’une manière très concrète : • Ecriture du code source • Ecriture des tests unitaires associés • Intégration du travail d’implémentation • Artefact : ‘Build’, exécutable contenant une version sommaire du produit ﬁnal

Deployment • Activités liées au conditionnement du produit • Objectif : mise à disposition des utilisateurs • Pas forcément uniquement en ﬁn de projet • Tests privés puis de plus en plus élargis • Artefact : le produit, avec une documentation de déploiement

Tests • Vériﬁer continuellement la qualité • Ecriture de tests de non régression • Tests unitaires • Tests fonctionnels • Artefacts : test plan (stratégie de tests), test suite (implémentation des tests)

Artefact test plan • Description de la stratégie de tests • Eléments à tester • Outil à utiliser suivant les tests • Mesures produites • Ressources affectées à cette tâche

eXtreme Programing La première des méthodes dites ‘agiles’

XP : Une alternative • eXtreme Programming • Issu projets ‘difﬁciles’ appliquer des méthodes a des de recherches pour • Cahier des charges mouvant • Délais courts • Technologies mal maîtrisées Réputation de méthode orientée « e-Business » !

Philosophies de XP • Réconcilier l’humain avec la productivité • Faciliter le changement social • Voie d’amélioration • Style de développement • Discipline de développement d’applications informatiques • Réduire les coûts du changement

Principes de base • Objectif : éviter le développement « cow-boy » • Principes : • Communication • Feed back • Simplicité • Courage • Peut être trop ‘militant’ ?

Pragmatisme extrême • La revue du code est une bonne chose • Elle est systématisée • Les tests sont indispensables • On les écrits dès le départ • La conception est importante • On la pratique tout au long du projet

Pragmatisme extrême -2 • La simplicité permet d’aller plus vite • On choisit toujours la solution la plus simple • La compréhension est importante • On déﬁnit des métaphores • L’intégration des modiﬁcations est cruciale • Effectuée plusieurs fois par jours

Cycle de développement XP

Client sur site • L’eXtreme Programming ne peut se mettre en place que si le client est fortement impliqué • Dans l’idéal, un représentant du client ﬁnal doit être sur site pendant toute la durée du projet • Il connait l’utilisateur ﬁnal • Il doit avoir une vision globale du projet • Il réalise son travail habituel et est à disposition de l’équipe de développement

Collaboration avec le client • Les users stories peuvent compléter les uses cases, en reprenant les cas d’utilisation point par point • Amorce de dialogue moins formelle • Utilisation de ﬁches au format A5 • Implication active dans chaque itération

Planning Game • Implique Client et Développeur • Le client crée des scénarios • Celà lui donne un certain ‘contrôle’ sur le projet, sans être rhédibitoire pour le dév • L’équipe estime les temps de réalisation • Le client sélectionne les scénarios à réaliser et déﬁnit les priorités

Intégration continue • Dès qu’une tâche est terminée, on inclut les modiﬁcations au produit ﬁnal • Eviter une trop grosse tâche d’intégration pré-livraison • Rôle important et validant des tests

Petites livraisons • On limite au maximum la portée et l’importance d’une livraison • L’intégration continue doit faciliter cette tâche

Tests • L’écriture des tests unitaires précède le développement • Permet de prévenir les oublis • Anticipe les difﬁcultés • ‘Documente’ le développement • Les tests de recette (tests fonctionnels) sont déﬁnis conjointement avec le client • Valident et clôturent une itération

Rythme de travail • Pas d’heures supplémentaires deux semaines de suite • Un développeur fatigué travaille mal • Chaque tâche doit être limitée à une journée • La journée doit se terminer par une ﬁn de tâche • Le code est relu le lendemain matin • Permet de jauger “l’odeur” du travail de la veille

Refactoring de code • Autorisé et même conseillé • Jauger « l’odeur » d’un code • N’apporte rien au client, maisenvironnement développeur d’améliorer son permet au • Appropriation collective du code • L’équipe est responsable collectivement de l’application • On peut modiﬁer un code qui n’est pas le sien • Les tests seront les juges de paix

Pair programming • Programmation en binômes • Binômes tournant • Améliorer la connaissance collective de l’application • Tout code est relu • Celui qui n’est pas au clavier prend du recul • Echanges de savoir faire et transfert de compétences

Changements • Ne sont pas vus comme une fatalité (gérée par les itérations) • Sont incorporés comme une notion naturelle • Accompagnent l’évolution d’un logiciel Et la maintenance logicielle ?

Convention de nommage • Pour permettre une appropriation collective • Il faut établir et respecter des conventions • Vocabulaire utilisé • Nommages des classes, méthodes,... • Utilisation de métaphores • Ne pas utiliser de termes savants là où une analogie peut clariﬁer la situation

Nonlinear management • Le mode de management non linéaire est présenté comme une évolution encore plus extrême des méthodes agiles • Une totale liberté est laissée sur la forme, seule l’objectif compte • Ex : «je vous laisse maître de l’implémentation d’une classe à condition que l’on conçoive ensemble son interface» • Beaucoup de projets communautaires fonctionnent ainsi • Ex : Linux, wikipedia..

Fonctionnement non linéaire • Le rôle du chef de projet est de dégager des “tickets”, avec une unité de temps <=1jour • Création de fonction • Modiﬁcation/Refacto • Debug • Les développeurs gardent une marge de décision sur l’ordre des tâches à accomplir

Gestion du planning • On se ﬁxe des sous projets (milestone) avec des dates limites • Des graphes de progression permettent de visualiser les progrès accomplis • On utilise le plus souvent des outils online pour gérer les projets (ex : TRAC, Sourceforge...)

Particularités • Nécessite une grande cohésion d’équipe et une motivation accrue • Le côté “liberté” et “on gagne ensemble” jour en la faveur de la motivation • Implique une préparation intense de la part du chef de projet • La liberté doit reposer sur un projet extrêmement bien cadré et préparé

SCRUM Agilité et travail d’équipe

Scrum : le jeu «collectif» • Scrum est, à l’instar de XP, une méthode agile de conduite de projets • Mais plus orientée «conduite d’équipes» • Contrairement à XP, le rôle du «chef d’équipe» est bien explicité • Scrum signiﬁe «mêlée», au sens du Rugby • Aller de l’avant ensemble, avec un même objectif

Grands principes • Individus vs Processus/Outils • Collaboration du client vs contrat • Réponse au changement vs plan déﬁni à l’avance • Logiciel vs documentation exhaustive

Les intervenants de Scrum

Les acteurs de Scrum • Directeur de produit : le ‘représentant’ du projet, la maîtrise d’ouvrage • L’équipe : sans hiérarchie particulière, chargée de l’exécution des tâches • Le ‘Scrum master’ : en charge de l’ordonnancement des tâches et ‘tampon’ entre le client et les exécutants • Les ‘Skateholders’ sont des intervenants extérieurs (consultants, experts, agents de direction..)

Planiﬁcation • Sprints : entre 2 et 4 semaines • Releases : sorties effectives du logiciel • Une release est constituée de sprints • Quotidien : ScrumMeeting de mise au point

Contenu d’un sprint • Un sprint est constitué de tâches, piochées dans le Product Backlog • But du jeu : vider le product backlog • Les tâches peuvent être : • Des users stories (déﬁnies par le product owner) • Des technical stories (déf par l’archi technique)

User stories • Une user story est une phrase du type : • «En tant que [role], je [feature] pour [reason]» • Ex : «En tant qu’utilisateur, je me connecte pour entrer dans l’application» • Certaines stories sont particulières : • des «Epic» sont des futures stories trop larges et destinées à être fragmentées • des «Spike» sont des tâches de prototypages techniques

Notation des user stories • Chaque user story est ‘notée’ pour quantiﬁer sa complexité • Par de lien direct avec une estimation en jours de travail • Permet ensuite de comptabiliser les points pour le suivi projet • On utilise souvent la suite de Fibonacci pour éviter les notes trop proches (1,2,3,5,8,13)

Planning Poker • Il existe des outils permettant de poser un consensus sur la complexité des divers User Stories • Sorte de ‘vote’ par les membres de l’équipe

Burndown chart • Chaque tâche est liée à un nombre de points • Le but du jeu d’une release est de réduire à zéro les points constités par le cumul de ses tâches • Permet une visualisation temps réel de l’avancée du projet • Il existe des graphiques pour visualiser une release, mais aussi un sprint

Scrum et conduite d’équipe • Une user story peut être allouée telle qu’elle à un développeur, mais il vaut mieux utiliser une méthode «XP» : • Une user story est alors découpée en tâches d’une journée maximum • Chaque tâche est ensuite allouée à selon la méthode de conduite d’équipe choisie : • Soit par le ScrumMaster • Soit par volontariat par le dév/exécutant

La Cathédrale et le Bazar Le modèle de développement du logiciel libre

Le premier ‘bazar’ : Linux • Un projet d’envergure, international • Un ‘leader’ très peu dirigiste (Linus Torvalds) • L’utilisation intensive d’outils de versioning et d’Internet • Opposition complète à la notion de ‘Cathédrale’, beaucoup plus hiérarchique et dirigiste

Ouvrir un bazar ? Les prérequis • Un coordinateur • Pas forcément le meilleur technicien • Mais apte à reconnaître le talent des autres...et leurs idées • Avec un certain charisme, un bon contact • Un amorçage avec une ‘promesse plausible’ • Le noyau 0.01 de Linux

Le noyau Linux • Des années de développement (presque 20 ans entre la 0.01 et la 2.6.32 !) • Linus se présente comme un «dictateur bienveillant» • Des milliers de contributeurs ! • Des ‘mainteners’ pour les versions stabilisées • Nouvelle version toutes les 8 semaines en moyenne • Après différents choix, l’équipe utilise aujourd’hui le gestionnaire de version Git

Quelques règles... • Chaque bon projet commence par un premier ‘draft’ lancé par l’initiateur • Les bons programmeurs savent écrire. Les excellents savent quoi réécrire • Préparez vous à jeter.Vous le ferez, de toute manière • Si vous perdez de l’intérêt, passez la main • ‘Releasez’ tôt et souvent • Abusez des beta-testeurs et classez les problèmes

Quelques règles (suite) • De bonnes structures de données et un code pourri fonctionneront mieux que l’inverse • Traitez au mieux vos beta-testeurs • Le design ‘parfait’ est atteint non pas quand plus rien n’est à implémenter, mais quand plus rien n’est à enlever • Un outil doit être utile, mais un vraiment bon outil vous amène des possibilités inattendues • Ecoutez vos utilisateurs

Boite à outils Utiliser le formalisme UML et divers autres outils dans la conduite de projets

Mener un projet en s’appuyant sur UML • Xième rappel : UML n’est pas une méthodologie objet • Mais c’est une “boîte à outils” permettant de tout envisager dans ce domaine • On peut donc aisément utiliser les divers diagrammes tout au long de la vie du projet

Séquence de tâches dans un projet UML Use cases Découpage Méthodes Interface Structure base de utilisateur données Données publiques Diagramme de Structure classes classes Diagrammes Corps dynamiques méthodes

Les éditeurs UML • Il en existe de nombreux • Certains génèrent le code objet à partir du diagramme de classes • Certains permettent même du ‘reverse engineering’

Maquettes d’interface • Pour concevoir les maquettes, un outil spéciﬁque permet de les créer en disjoignant complètement les questions esthétiques • C’est un «mockup» • Ex : Balsamiq Mockups

Tests Limiter la régression et aller vers une meilleure qualité du logiciel

Tests unitaires • Principe : une batterie de tests (par classe, par méthode...) formalisés et réutilisables • Objectifs : • Regrouper vos tests • Pouvoir les appeler/rappeler en bloc • Tests de non régression

Conception par contrats • Pour valider le fonctionnement d’une classe • Principe de classe autotestable • Principes d’un contrat : • Destiné a formaliser des spéciﬁcations et de la documentation • Sert à la mise au point et aux tests

Contrats et langage • Notion de contrat introduite par Bertrand Meyer L’inventeur du langage Eiffel Travaille a l’intégration de ses technologies dans .Net Naturellement, on retrouve la notion de contrat dans Eiffel (et dans Python) Les autres langages objets peuvent s’adapter

Tests de classes • Tests unitaires : comportement d’un objet isolé • Pas toujours probant • Validation de composants • Suivi de scénario d’échange de messages entre quelques classes • Suivant le périmètre, on s’approche : • Des tests unitaires • Ou des tests d’intégration

Boîte blanche / noire • Boîte blanche : approche classique, procédurale • Permet de tester plus précisément certains points faibles d’une classe • Ne fera pas apparaître des oublis et incohérences vis à vis des specs • Contraire au principe d’encapsulation

Boîte noire • Conforme à l’encapsulation d’un objet • Privilégie l’interface sur l’implémentation • Principes d’oracles • Permettent de déterminer si un test s’effectue correctement ou non • Ont souvent besoin de données internes aux classes • On met en place des indicateurs (sous forme de méthodes) spéciﬁquement pour les tests

Tests de non régression • Composants objets réutilisables • Durée de vie parfois longue Importance de la validation des composants Chaque opération de maintenance entraîne de nouveaux tests

Assertions • Clause à vériﬁcation obligatoire • Assertions de contrat • S’insèrent dans l’interface • Tests de type boîte noire • Assertions internes • Tests de type boîte blanche • Contrats + Assertions Outils pour écrire des scénarios de tests

Design By Contract (DBC) • Mis au point par Bertrand Meyer • Langage Eiffel • Concept : notion de contrat entre le développeur d’API et l’utilisateur de ces APIs • Basé sur la notion d’assertions • Vériﬁcation de tests donnant “vrai” ou “faux”

Que tester ? • Il n’est pas très utile de systématiser les tests • Plutôt que de favoriser les “trains qui arrivent à l’heure”, favoriser les cas limites • “Crashs tests” • Musée des horreurs de l’utilisation de vos classes

Exemples de tests (TP formes géom.) • Paramètres à envoyer (style : “10 12 15”) • Envoyer trop de paramètres • Envoyer pas assez de paramètres • Envoyer des lettres au lieu de chiffres • Formes en dehors de la surface • Fichier • Fichier vide • Fichier inexistant • Nombre de lignes impairs

Versions logicielles Maîtrise de l’évolution du software dans le temps

Contrôle de version • Permet de gérer et de numéroter les versions d’un logiciel • Indispensable pour gérer du travail en groupe et l’historique d’un logiciel • Historiquement, on utilisait l’outil cvs • Aujourd’hui, on utilise plutôt svn

Exemple de versioning • svn add list txt • svn ci list.txt -m “ajout a la liste”

Synchronisation serveur/ version locale • svn co list.txt • svn ci list.txt • svn revert list.txt • svn co -r2 list.txt

Comparaison deux ﬁchiers • La commande diff permet de visualiser les différences entre deux ﬁchiers • svn diff -r3:4 list.txt

Création d’une branche • svn copy http://...trunk http://....branch

Fusion de versions • svn merge -r5:6 http://...trunk

Tagging • svn copy http://...trunk http://...tag

Qualité De la conduite de projet vers la qualiﬁcation des livrables

Démarche qualité • Objectif : introduire des démarches de contrôle qualité au niveau du code source • On passe de plus en plus par des automates • Il existe aujourd’hui des “suites” de logiciels de contrôle et d’audit de code

Suites de qualité logicielle Java • Ex : XRadar, Sonar... • Compilation de plusieurs outils : • CheckStyle : vériﬁcation des nommages et styles de codes • PMD : contrôle qualité sur la nature même du code • JDepend : visualisation des dépendances entre classes • JavaNCSS : métrique de code

Exemple d’analyse avec PMD • PMD s’intègre a Eclipse • Mais pour systématiser les tests, il vaut mieux les inclure dans un système automatisant (chaque nuit ?) les audits

Etat récapitulatif avec Sonar

Tests de montée en charge

Montée en charge avec JMeter

AntiPatterns L’apprentissage par l’erreur

Anti-Patterns • De la même manière que les Patterns sont des modèles de conception.. • ..des anti-patterns sont des modèles de ce qu’il ne faut pas faire • Sorte de “worst-of” des pratiques • dans le logiciel • dans l’entreprise en général

Anti-patterns de développeurs • Abstraction inverse : être obligé d’utiliser un objet dont l’interface est trop complexe par rapport à l’usage simple qui est le vrai besoin • Action à distance : emploi abusif de variables globales et de dépendances entre classes externes • Ancre de bateau : composant inutilisé mais gardé dans le code “au cas où”

Anti-patterns de développeurs • Copier/Coller : fameux syndrôme du développeur de duplication de code erroné ou de non-adaptation de code La programmation ‘Pizza’ • Programmation spaghetti est en revanche conseillée ! • Programmation plat de lasagnes : impossibilité d’intervenir sur les couches inférieures • Réinventer la roue carrée : réinventer une mauvaise solution

Anti-patterns de développeurs • Coulée de lave : Passer en prod un code immature, ce qui va ‘solidiﬁer’ les bugs en empêchant leur modiﬁcation • Surcharge des interfaces utilisateurs • Objet divin : composant effectuant trop de tâches essentielles

Anti-patterns de conduite de projets • 30,000 feet and climbing : Modèle ultra- pyramidal • Bleeding edge : recours systématique à des technologies immatures • Brain trust parking lot : cumulation inutile de “grosses têtes” • Buzzword driven architecture (ou Architecture by magazine) : accumulation de technos “à la mode” sans justiﬁcation

http://www.360emedia.fr	197
http://www.slideshare.net	17
http://webcache.googleusercontent.com	1

Genielogiciel

by Jean David Olekhnovitch on Jan 24, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 215

Statistics

Genielogiciel — Presentation Transcript