SlideShare une entreprise Scribd logo
1  sur  143
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
Planification

• 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érifie toujours... sauf
   lorsqu’on cherche à la vérifier
• 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
 • Difficile 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éfinition, 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écifications
 • ...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 fil du temps
• Sans forcément en faire bénéficier 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) Unified Process
La première méthode liée aux concepts objets
Méthode liée à UML :
         RUP
• Rational Unified 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 difficile 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éfinis 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écifiés en terme informatique
• Réalisés par la conception
• Concrètement implémentés par les
  développeurs
• Vérifié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 simplifier 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 modifié
  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 workflow (UML)
• Il existe 6 disciplines d’ingénierie (voir cycles
  page suivante), et 3 disciplines de support
  (Project, Configuration, 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éfinitions 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 identifié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 affine 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 final
Deployment

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

• Vérifier 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 ‘difficiles’ 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éfinit des métaphores
• L’intégration des modifications 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 final doit
  être sur site pendant toute la durée du projet
 • Il connait l’utilisateur final
 • 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 fiches 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éfinit les priorités
Intégration continue

• Dès qu’une tâche est terminée, on inclut les
  modifications au produit final
 • 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 difficultés
 • ‘Documente’ le développement
• Les tests de recette (tests fonctionnels) sont
  définis 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 fin 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 modifier 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 clarifier 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
 • Modification/Refacto
 • Debug
• Les développeurs gardent une marge de
  décision sur l’ordre des tâches à accomplir
Gestion du planning

• On se fixe 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 signifie «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éfini à
  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..)
Planification
• 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éfinies 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 quantifier 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écifique 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écifications 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écifiquement 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érification 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érification 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
             fichiers
• La commande diff permet de visualiser les
  différences entre deux fichiers
• 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 qualification 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érification 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 ‘solidifier’ les bugs en
  empêchant leur modification
• 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 justification

Contenu connexe

Tendances

Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agilesGuillaume Collic
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projetsCGI Québec Formation
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement MicrosoftChristophe HERAL
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange LabsEmmanuel Hugonnet
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPSarah
 
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011Henri Gomez
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisJason De Oliveira
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !Lucian Precup
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011Henri Gomez
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionTremeur Balbous
 

Tendances (20)

Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agiles
 
Les usines à logiciels
Les usines à logicielsLes usines à logiciels
Les usines à logiciels
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projets
 
2011 XKE - Kanban in action
2011 XKE - Kanban in action2011 XKE - Kanban in action
2011 XKE - Kanban in action
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Method XP
Method XP Method XP
Method XP
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XP
 
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 

En vedette

Java - notions de bases pour développeur
Java - notions de bases pour développeurJava - notions de bases pour développeur
Java - notions de bases pour développeurJean David Olekhnovitch
 
Télétravail et égilité : un mariage impossible ?
Télétravail et égilité : un mariage impossible ?Télétravail et égilité : un mariage impossible ?
Télétravail et égilité : un mariage impossible ?Jean David Olekhnovitch
 
Java - implémentation des concepts objets
Java - implémentation des concepts objetsJava - implémentation des concepts objets
Java - implémentation des concepts objetsJean David Olekhnovitch
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Ardesi Midi-Pyrénées
 
Projet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoinsProjet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoinsJean-Marc Dupont
 
Finagle Your Own Codec - Scala By The Bay 2016
Finagle Your Own Codec - Scala By The Bay 2016Finagle Your Own Codec - Scala By The Bay 2016
Finagle Your Own Codec - Scala By The Bay 2016Chris Phelps
 
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015Publicis Sapient Engineering
 
Comparaison des solutions Paas
Comparaison des solutions PaasComparaison des solutions Paas
Comparaison des solutions Paasyacine sebihi
 
Bcdi3rec
Bcdi3recBcdi3rec
Bcdi3recljvdb
 
Formation gestion de projet - 05 - la conception
Formation gestion de projet - 05 - la conceptionFormation gestion de projet - 05 - la conception
Formation gestion de projet - 05 - la conceptioniafactory
 
Formation gestion de projet - 06 - la production
 Formation gestion de projet - 06 - la production Formation gestion de projet - 06 - la production
Formation gestion de projet - 06 - la productioniafactory
 

En vedette (20)

Java - notions de bases pour développeur
Java - notions de bases pour développeurJava - notions de bases pour développeur
Java - notions de bases pour développeur
 
Télétravail et égilité : un mariage impossible ?
Télétravail et égilité : un mariage impossible ?Télétravail et égilité : un mariage impossible ?
Télétravail et égilité : un mariage impossible ?
 
Internet mobile
Internet mobileInternet mobile
Internet mobile
 
Plan d'action WAI
Plan d'action WAIPlan d'action WAI
Plan d'action WAI
 
Java - implémentation des concepts objets
Java - implémentation des concepts objetsJava - implémentation des concepts objets
Java - implémentation des concepts objets
 
Ecommerce
EcommerceEcommerce
Ecommerce
 
Agilité et Entreprise libérée
Agilité et Entreprise libéréeAgilité et Entreprise libérée
Agilité et Entreprise libérée
 
JAVA, JDBC et liaison base de données
JAVA, JDBC et liaison base de donnéesJAVA, JDBC et liaison base de données
JAVA, JDBC et liaison base de données
 
Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
 
Analyse et cahier des charges
Analyse et cahier des chargesAnalyse et cahier des charges
Analyse et cahier des charges
 
Projet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoinsProjet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoins
 
Finagle Your Own Codec - Scala By The Bay 2016
Finagle Your Own Codec - Scala By The Bay 2016Finagle Your Own Codec - Scala By The Bay 2016
Finagle Your Own Codec - Scala By The Bay 2016
 
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015
Un jenkins amélioré avec docker mesos et marathon à Devoxx 2015
 
Comparaison des solutions Paas
Comparaison des solutions PaasComparaison des solutions Paas
Comparaison des solutions Paas
 
Projet pmb
Projet pmbProjet pmb
Projet pmb
 
Projet Pmb
Projet PmbProjet Pmb
Projet Pmb
 
Bcdi3rec
Bcdi3recBcdi3rec
Bcdi3rec
 
Formation gestion de projet - 05 - la conception
Formation gestion de projet - 05 - la conceptionFormation gestion de projet - 05 - la conception
Formation gestion de projet - 05 - la conception
 
Formation gestion de projet - 06 - la production
 Formation gestion de projet - 06 - la production Formation gestion de projet - 06 - la production
Formation gestion de projet - 06 - la production
 

Similaire à Genielogiciel

AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilitéChristophe Addinquy
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfboulonvert
 
Mener à bien un projet Drupal (Drupagora 2013)
Mener à bien un projet Drupal (Drupagora 2013)Mener à bien un projet Drupal (Drupagora 2013)
Mener à bien un projet Drupal (Drupagora 2013)LaNetscouade
 
presentationSCRUM.pptx
presentationSCRUM.pptxpresentationSCRUM.pptx
presentationSCRUM.pptxFaouziRBEIHI
 
a Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les fluxa Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les fluxDanielMohamed4
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelAgile Montréal
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgileAgile Tour 2009 Québec
 
Agile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima ExpertsAgile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima ExpertsMarc-Eric LaRocque
 
Solutions Web « prêtes à porter » avec WordPress
Solutions Web « prêtes à porter » avec WordPressSolutions Web « prêtes à porter » avec WordPress
Solutions Web « prêtes à porter » avec WordPressStéphane Plante
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesRomain Couturier
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxtestuser715939
 
Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks Hidora
 

Similaire à Genielogiciel (20)

L'Agilité chez GEE Montréal
L'Agilité chez GEE MontréalL'Agilité chez GEE Montréal
L'Agilité chez GEE Montréal
 
chapitre 1 SI.pdf
chapitre 1 SI.pdfchapitre 1 SI.pdf
chapitre 1 SI.pdf
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdf
 
Agile Tour Lille 2008
Agile Tour Lille 2008Agile Tour Lille 2008
Agile Tour Lille 2008
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Mener à bien un projet Drupal (Drupagora 2013)
Mener à bien un projet Drupal (Drupagora 2013)Mener à bien un projet Drupal (Drupagora 2013)
Mener à bien un projet Drupal (Drupagora 2013)
 
presentationSCRUM.pptx
presentationSCRUM.pptxpresentationSCRUM.pptx
presentationSCRUM.pptx
 
a Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les fluxa Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les flux
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Agility with scrum
Agility with scrumAgility with scrum
Agility with scrum
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Agile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima ExpertsAgile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima Experts
 
Solutions Web « prêtes à porter » avec WordPress
Solutions Web « prêtes à porter » avec WordPressSolutions Web « prêtes à porter » avec WordPress
Solutions Web « prêtes à porter » avec WordPress
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
1.pdf
1.pdf1.pdf
1.pdf
 
Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks
 

Genielogiciel

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. Planification • 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
  • 9. 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
  • 10. 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)
  • 11. 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
  • 12. 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
  • 13. Encore pire • Cercle vicieux de Carvey : • La Loi de Murphy se vérifie toujours... sauf lorsqu’on cherche à la vérifier • Loi de Paquel : • La caractéristique la plus constante de l’informatique est la capacité des utilisateurs à saturer tout système mis à disposition
  • 14. 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
  • 15. Artisanat ? • Succès d’un projet encore essentiellement lié à la compétence de ses acteurs • Fabrication sur mesure • Difficile de reproduire une démarche d’un projet à l’autre • Technologies récentes, en pleine évolution
  • 16. 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
  • 17. Cycles de développement Ordonnancer son projet
  • 18. 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
  • 20. 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
  • 21. 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éfinition, permet des organisations plus souples
  • 23. 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écifications • ...et vice versa • Adapté lorsqu’un projet nécessite une certaine montée en puissance
  • 24. 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 fil du temps • Sans forcément en faire bénéficier le projet en cours
  • 25. 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 ;)
  • 26.
  • 27. Cycle itératif • Objectif : livrer quelque chose d’incomplet, mais au plus vite • Apprendre par l’erreur • Doit accompagner des méthodes dites “agiles”
  • 29. 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
  • 30. RUP (Rational) Unified Process La première méthode liée aux concepts objets
  • 31. Méthode liée à UML : RUP • Rational Unified Process • Suite des travaux des ‘three amigos’ • Méthode vendue par Rational • Particulièrement adapté à UML et au développement objet
  • 32. 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 difficile car vocabulaire dense • Mais méthode validée à de nombreuses occasions
  • 33. 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
  • 34. Fondement de RUP • RUP est : • Piloté par les cas d’utilisation • Centré sur l’architecture • Itératif et incrémental
  • 35. 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 ?
  • 36. Processus et cas d’utilisation • Le processus est piloté par les cas d’utilisations définis 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
  • 37. 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
  • 38. Quand exploiter les use cases ? • Les uses cases sont détaillés lors de l’analyse • Puis spécifiés en terme informatique • Réalisés par la conception • Concrètement implémentés par les développeurs • Vérifiés par les scénarios de tests
  • 39. 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
  • 40. 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
  • 43. 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…)
  • 44. 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
  • 45.
  • 46. Packages de use cases • Permet de simplifier des schémas de use cases • Utile dans le cas d’implémentation d’application métier
  • 47. 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
  • 48. 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
  • 49. Notion d’artefact • Un artefact est un élément produit ou modifié 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...
  • 50. Notion de rôle • Ensemble d’activités et de responsabilités • Analystes • Développeurs • Testeurs • Managers
  • 51. Notion de discipline • Une discipline est un agrégat d’activités, associé à : • Des artefacts • Un workflow (UML) • Il existe 6 disciplines d’ingénierie (voir cycles page suivante), et 3 disciplines de support (Project, Configuration, Environment)
  • 52. 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
  • 53. 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 !
  • 55. 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
  • 56. 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
  • 57. Gestion des exigences (requirements) • On passe ici des définitions métier aux exigences du projet • Rôle essentiel du client, puisque c’est ici qu’il donne ses exigences et recommandations
  • 58. 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 identifiés et associés au projet • User Interface Prototype : première version de l’interface graphique (ex: maquette HTML)
  • 59. 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
  • 60. 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
  • 61. Implémentation • On affine 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 final
  • 62. Deployment • Activités liées au conditionnement du produit • Objectif : mise à disposition des utilisateurs • Pas forcément uniquement en fin de projet • Tests privés puis de plus en plus élargis • Artefact : le produit, avec une documentation de déploiement
  • 63. Tests • Vérifier 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)
  • 64. 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
  • 65. eXtreme Programing La première des méthodes dites ‘agiles’
  • 66. XP : Une alternative • eXtreme Programming • Issu projets ‘difficiles’ 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 » !
  • 67. 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
  • 68. Principes de base • Objectif : éviter le développement « cow-boy » • Principes : • Communication • Feed back • Simplicité • Courage • Peut être trop ‘militant’ ?
  • 69. 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
  • 70. 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éfinit des métaphores • L’intégration des modifications est cruciale • Effectuée plusieurs fois par jours
  • 72. 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 final doit être sur site pendant toute la durée du projet • Il connait l’utilisateur final • Il doit avoir une vision globale du projet • Il réalise son travail habituel et est à disposition de l’équipe de développement
  • 73. 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 fiches au format A5 • Implication active dans chaque itération
  • 74. 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éfinit les priorités
  • 75. Intégration continue • Dès qu’une tâche est terminée, on inclut les modifications au produit final • Eviter une trop grosse tâche d’intégration pré-livraison • Rôle important et validant des tests
  • 76. Petites livraisons • On limite au maximum la portée et l’importance d’une livraison • L’intégration continue doit faciliter cette tâche
  • 77. Tests • L’écriture des tests unitaires précède le développement • Permet de prévenir les oublis • Anticipe les difficultés • ‘Documente’ le développement • Les tests de recette (tests fonctionnels) sont définis conjointement avec le client • Valident et clôturent une itération
  • 78. 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 fin de tâche • Le code est relu le lendemain matin • Permet de jauger “l’odeur” du travail de la veille
  • 79.
  • 80. 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 modifier un code qui n’est pas le sien • Les tests seront les juges de paix
  • 81. 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
  • 82. 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 ?
  • 83. 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 clarifier la situation
  • 84. 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..
  • 85. 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 • Modification/Refacto • Debug • Les développeurs gardent une marge de décision sur l’ordre des tâches à accomplir
  • 86. Gestion du planning • On se fixe 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...)
  • 87. 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é
  • 89. 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 signifie «mêlée», au sens du Rugby • Aller de l’avant ensemble, avec un même objectif
  • 90. Grands principes • Individus vs Processus/Outils • Collaboration du client vs contrat • Réponse au changement vs plan défini à l’avance • Logiciel vs documentation exhaustive
  • 92. 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..)
  • 93. Planification • Sprints : entre 2 et 4 semaines • Releases : sorties effectives du logiciel • Une release est constituée de sprints • Quotidien : ScrumMeeting de mise au point
  • 94. 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éfinies par le product owner) • Des technical stories (déf par l’archi technique)
  • 95. 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
  • 96. Notation des user stories • Chaque user story est ‘notée’ pour quantifier 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)
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. La Cathédrale et le Bazar Le modèle de développement du logiciel libre
  • 101. 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
  • 102. 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
  • 103. 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
  • 104. 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
  • 105. 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
  • 106. Boite à outils Utiliser le formalisme UML et divers autres outils dans la conduite de projets
  • 107. 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
  • 108. 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
  • 109. 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’
  • 110. Maquettes d’interface • Pour concevoir les maquettes, un outil spécifique permet de les créer en disjoignant complètement les questions esthétiques • C’est un «mockup» • Ex : Balsamiq Mockups
  • 111. Tests Limiter la régression et aller vers une meilleure qualité du logiciel
  • 112. 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
  • 113. Conception par contrats • Pour valider le fonctionnement d’une classe • Principe de classe autotestable • Principes d’un contrat : • Destiné a formaliser des spécifications et de la documentation • Sert à la mise au point et aux tests
  • 114. 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
  • 115. 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
  • 116. 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
  • 117. 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écifiquement pour les tests
  • 118. 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
  • 119. Assertions • Clause à vérification 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
  • 120. 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érification de tests donnant “vrai” ou “faux”
  • 121. 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
  • 122. 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
  • 123. Versions logicielles Maîtrise de l’évolution du software dans le temps
  • 124. 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
  • 125. Exemple de versioning • svn add list txt • svn ci list.txt -m “ajout a la liste”
  • 126. Synchronisation serveur/ version locale • svn co list.txt • svn ci list.txt • svn revert list.txt • svn co -r2 list.txt
  • 127. Comparaison deux fichiers • La commande diff permet de visualiser les différences entre deux fichiers • svn diff -r3:4 list.txt
  • 128. Création d’une branche • svn copy http://...trunk http://....branch
  • 129. Fusion de versions • svn merge -r5:6 http://...trunk
  • 130. Tagging • svn copy http://...trunk http://...tag
  • 131. Qualité De la conduite de projet vers la qualification des livrables
  • 132. 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
  • 133. Suites de qualité logicielle Java • Ex : XRadar, Sonar... • Compilation de plusieurs outils : • CheckStyle : vérification 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
  • 134. 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
  • 136. Tests de montée en charge
  • 137. Montée en charge avec JMeter
  • 139. 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
  • 140. 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ù”
  • 141. 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
  • 142. Anti-patterns de développeurs • Coulée de lave : Passer en prod un code immature, ce qui va ‘solidifier’ les bugs en empêchant leur modification • Surcharge des interfaces utilisateurs • Objet divin : composant effectuant trop de tâches essentielles
  • 143. 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 justification