Génie logiciel
      Méthodes de conduite de projet
       Tester, optimiser, structurer
              ses applications
  ...
Prologue :
  The Mythical Man Month
• Livre écrit en 1975
• Témoignage sur l’expérience
  d’un projet s’engluant dans la
 ...
Loi de Brooks

• “Ajouter des ressources humaines à un projet en
  retard ne fait qu’accentuer ce retard”
 • Ces personnes...
L’effet “deuxième
           système”

• Un informaticien n’ayant pas eu le temps
  d’inclure certaines fonctions dans un ...
L’unité conceptuelle

• Préserver l’unité de la conception d’un projet
  en séparant son architecture de son
  implémentat...
Le prototype

• Toute nouvelle orientation technique est
  précédée d’un prototype
• Sert à la conception du programme ave...
Documents de base
• Rédigés par l’architecte du projet
 • Quels sont les objectifs
 • Comment les atteindre
 • Qui est res...
Planification

• Se souvenir du coût d’une tâche
 • Certaines tâches sont bien plus coûteuses
   que d’autres, techniquemen...
Le “chirurgien en chef”
• En chirurgie, toute opération est hiérarchisée
  par les compétences de chacun
 • Un chirurgien ...
L’âge de glace

• Chaque projet doit gérer des périodes de
  “gel”, caractérisés par des deadlines officielles :
 • Gel des...
Outils sur commande
• Plutôt que chacun développe ses outils dans
  son coin
• Inclure une personne dans le projet qui ser...
Prologue-bis :
          les lois de Murphy
• Une chose n’est jamais aussi simple qu’elle n’en a
  l’air
• Tout prend plus...
Encore pire
• Cercle vicieux de Carvey :
 • La Loi de Murphy se vérifie toujours... sauf
   lorsqu’on cherche à la vérifier
...
Industrialisation ?

• Faut il industrialiser le développement logiciel ?
• Utilisé ici par opposition à “artisanal”
 • Ta...
Artisanat ?

• Succès d’un projet encore essentiellement lié à
  la compétence de ses acteurs
• Fabrication sur mesure
 • ...
Normalisation et
        rationalisation
• Cette transition de l’artisanat à “l’industrie”
  logicielle passe par différen...
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...
En cascade
En cascade

• Directement hérité des méthodes utilisées
  dans les conceptions “en dur”
 • Bâtiment...
• Simple bon sens :...
En cascade
• Adapté à un processus logiciel ?
• Oui :
 • Forcer à faire les choses dans l’ordre
   implique une certaine d...
Cycle en V
Cycle en V
• Méthode classique de “feedback” de projet :
 • Chaque étape fait écho à une étape
   précédente
 • Ex : les t...
Cycle en V
• Plus le “V” descend profond, plus les erreurs
  de conceptions peuvent être importantes
 • Et le temps perdu ...
Cycles en spirales

• Il s’agit simplement de cycles découpés en
  plusieurs “V”
• Permet de prendre en compte la notion d...
Cycle itératif

• Objectif : livrer quelque chose d’incomplet,
  mais au plus vite
• Apprendre par l’erreur
• Doit accompa...
Cycle
itératif
Cycle itératif

• Nécessite une grande réactivité de la part du
  “client”
• Bien adapté dans le cadre de projets “glissan...
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 Ra...
Utilisation de RUP
• Conçu dans le cadre de projets énormes
 • Gestion commerciale Ericsson
• Très (trop) lourd pour des p...
4 P du développement
         objet
• Personnes
 • Rôle joué par les acteurs d’une problématique
• Projet
 • Le projet fai...
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 : comme...
Processus et cas
         d’utilisation
• Le processus est piloté par les cas
  d’utilisations définis dans la première pha...
Les Use Cases

• Analyse Fonctionnelle basée sur la notions
  d’acteurs
• Compréhensibles à la fois par les développeurs
 ...
Quand exploiter les use
       cases ?
• Les uses cases sont détaillés lors de l’analyse
 • Puis spécifiés en terme informa...
Notion d’acteur

• Entité externe (être humain, mécanisme
  matériel, autre programme…)
• Doit interagir avec le système à...
Différents acteurs
• Acteur ‘humain’ : le stick man
• Acteur système : rectangle


• Acteur principal : agit directement s...
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
 • Descripti...
Relations entre cas
• Déclenche : entre un acteur principal et un cas
  d’utilisation
• Utilise (include) : entre deux cas...
Packages de use cases
• Permet de simplifier des schémas de use cases
• Utile dans le cas d’implémentation d’application mé...
Notion d’architecture

• Au sens de RUP, une architecture :
 • Sert à comprendre le système lorsqu’il est
   complexe
 • P...
Architecture

• Fait le lien entre l’analyse et l’implémentation
  physique
 • Maîtrise technique
 • Elements structuraux
...
Notion d’artefact

• Un artefact est un élément produit ou modifié
  dans le cadre d’un processus de
  développement
• Ca p...
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 ...
Enchaînements d’activité
• Expression des besoins
 • Use cases
• Analyse
 • Refonte par l’informaticien des use cases
• Co...
Gestion de projets par
          itération
• Cycle complet :
 • Business Modeling
 • Requirements
 • Analysis and design
 ...
Phases d’un
développement
Business Modeling

• Définir un modèle d’organisation
 • Identifier les acteurs
 • Identifier les processus métier, la vision...
Artefacts d’un business
       modeling
• Business Glossary : recensement des termes
  métiers utilisés, permettant d’avoi...
Gestion des exigences
    (requirements)

• On passe ici des définitions métier aux
  exigences du projet
• Rôle essentiel ...
Artefact des
          requirements
• Glossary : termes utilisés dans le projet
• Business Case & Vision : Recensement des...
Analyse et conception

• Objectif principal : traduire les cas d’utilisation
  en artefacts de conception du système
• On ...
Artefacts Analysis &
          Design
• Software architecture : description formelle de
  l’architecture du système
• Desi...
Implémentation
• On affine ici le modèle de conception d’une
  manière très concrète :
 • Ecriture du code source
 • Ecritu...
Deployment

• Activités liées au conditionnement du produit
 • Objectif : mise à disposition des utilisateurs
 • Pas forcé...
Tests

• Vérifier continuellement la qualité
• Ecriture de tests de non régression
• Tests unitaires
• Tests fonctionnels
•...
Artefact test plan

• Description de la stratégie de tests
 • Eléments à tester
 • Outil à utiliser suivant les tests
 • M...
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 ...
Philosophies de XP
• Réconcilier l’humain avec la productivité
• Faciliter le changement social
• Voie d’amélioration
• St...
Principes de base
• Objectif : éviter le développement « cow-boy »
• Principes :
 • Communication
 • Feed back
 • Simplici...
Pragmatisme extrême
• La revue du code est une bonne chose
 • Elle est systématisée
• Les tests sont indispensables
 • On ...
Pragmatisme extrême -2
• La simplicité permet d’aller plus vite
 • On choisit toujours la solution la plus simple
• La com...
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éa...
Collaboration avec le
         client
• Les users stories peuvent compléter les uses
  cases, en reprenant les cas d’utili...
Planning Game
• Implique Client et Développeur
• Le client crée des scénarios
 • Celà lui donne un certain ‘contrôle’ sur ...
Intégration continue

• Dès qu’une tâche est terminée, on inclut les
  modifications au produit final
 • Eviter une trop gro...
Petites livraisons


• On limite au maximum la portée et
  l’importance d’une livraison
• L’intégration continue doit faci...
Tests
• L’écriture des tests unitaires précède le
  développement
 • Permet de prévenir les oublis
 • Anticipe les difficul...
Rythme de travail

• Pas d’heures supplémentaires deux semaines de suite
 • Un développeur fatigué travaille mal
• Chaque ...
Refactoring de code
• Autorisé et même conseillé
 • Jauger « l’odeur » d’un code
 • N’apporte rien au client, maisenvironn...
Pair programming
• Programmation en binômes
• Binômes tournant
 • Améliorer la connaissance collective de
   l’application...
Changements

• Ne sont pas vus comme une fatalité (gérée par
  les itérations)
• Sont incorporés comme une notion naturell...
Convention de nommage
• Pour permettre une appropriation collective
 • Il faut établir et respecter des conventions
   • V...
Nonlinear management
• Le mode de management non linéaire est présenté
  comme une évolution encore plus extrême des
  mét...
Fonctionnement non
       linéaire
• Le rôle du chef de projet est de dégager des
  “tickets”, avec une unité de temps <=1...
Gestion du planning

• On se fixe des sous projets (milestone) avec
  des dates limites
• Des graphes de progression permet...
Particularités
• Nécessite une grande cohésion d’équipe et
  une motivation accrue
 • Le côté “liberté” et “on gagne ensem...
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 ...
Grands principes

• Individus vs Processus/Outils
• Collaboration du client vs contrat
• Réponse au changement vs plan défi...
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éra...
Planification
• Sprints : entre 2 et 4 semaines
• Releases : sorties effectives du logiciel
 • Une release est constituée d...
Contenu d’un sprint

• Un sprint est constitué de tâches, piochées dans le
  Product Backlog
 • But du jeu : vider le prod...
User stories
• Une user story est une phrase du type :
 • «En tant que [role], je [feature] pour [reason]»
 • Ex : «En tan...
Notation des user
             stories
• Chaque user story est ‘notée’ pour quantifier sa
  complexité
 • Par de lien direc...
Planning Poker

• Il existe des outils
  permettant de poser un
  consensus sur la
  complexité des divers
  User Stories
...
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 poi...
Scrum et conduite
             d’équipe
• Une user story peut être allouée telle qu’elle à un
  développeur, mais il vaut ...
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’ut...
Ouvrir un bazar ?
       Les prérequis
• Un coordinateur
 • Pas forcément le meilleur technicien
 • Mais apte à reconnaîtr...
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 ...
Quelques règles...
• Chaque bon projet commence par un premier ‘draft’
  lancé par l’initiateur
• Les bons programmeurs sa...
Quelques règles (suite)
• De bonnes structures de données et un code pourri
  fonctionneront mieux que l’inverse
• Traitez...
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 ...
Séquence de tâches dans
          un projet UML
                           Use cases                 Découpage


Méthodes ...
Les éditeurs UML
• Il en existe de
  nombreux
• Certains génèrent le
  code objet à partir du
  diagramme de classes
• Cer...
Maquettes d’interface

• Pour concevoir les
  maquettes, un outil
  spécifique permet de
  les créer en disjoignant
  compl...
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...
Conception par contrats

• Pour valider le fonctionnement d’une classe
 • Principe de classe autotestable
• Principes d’un...
Contrats et langage

 • Notion de contrat introduite par Bertrand Meyer
  L’inventeur du langage Eiffel
  Travaille a l’...
Tests de classes
• Tests unitaires : comportement d’un objet isolé
 • Pas toujours probant
• Validation de composants
 • S...
Boîte blanche / noire

• Boîte blanche : approche classique, procédurale
 • Permet de tester plus précisément certains
   ...
Boîte noire
• Conforme à l’encapsulation d’un objet
 • Privilégie l’interface sur l’implémentation
• Principes d’oracles
 ...
Tests de non régression

• Composants objets réutilisables
 • Durée de vie parfois longue
Importance de la validation des...
Assertions
• Clause à vérification obligatoire
• Assertions de contrat
 • S’insèrent dans l’interface
 • Tests de type boît...
Design By Contract
          (DBC)
• Mis au point par Bertrand Meyer
 • Langage Eiffel
• Concept : notion de contrat entre...
Que tester ?

• Il n’est pas très utile de systématiser les tests
• Plutôt que de favoriser les “trains qui arrivent
  à l...
Exemples de tests
                (TP formes géom.)
•   Paramètres à envoyer (style : “10 12 15”)

    •   Envoyer trop de...
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 ...
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 l...
Comparaison deux
             fichiers
• La commande diff permet de visualiser les
  différences entre deux fichiers
• svn d...
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 ...
Suites de qualité
             logicielle Java
• Ex : XRadar, Sonar...
• Compilation de plusieurs outils :
 • CheckStyle :...
Exemple d’analyse avec
         PMD
• PMD s’intègre a Eclipse
• Mais pour systématiser les tests, il vaut mieux
  les incl...
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è...
Anti-patterns de
        développeurs
• Abstraction inverse : être obligé d’utiliser un
  objet dont l’interface est trop ...
Anti-patterns de
        développeurs
• Copier/Coller : fameux syndrôme du
  développeur de duplication de code erroné ou
...
Anti-patterns de
        développeurs
• Coulée de lave : Passer en prod un code
  immature, ce qui va ‘solidifier’ les bugs...
Anti-patterns de
    conduite de projets
• 30,000 feet and climbing : Modèle ultra-
  pyramidal
• Bleeding edge : recours ...
Genielogiciel
Genielogiciel
Genielogiciel
Prochain SlideShare
Chargement dans…5
×

Genielogiciel

3 834 vues

Publié le

Support de cours de conduite de projets, en particulier pour le Web. Public visés : développeurs avec expérience, ou chefs de projets débutants

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 834
Sur SlideShare
0
Issues des intégrations
0
Intégrations
300
Actions
Partages
0
Téléchargements
240
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Genielogiciel

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. Cycles de développement Ordonnancer son projet
    18. 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
    19. 19. En cascade
    20. 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. 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
    22. 22. Cycle en V
    23. 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. 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. 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. 26. Cycle itératif • Objectif : livrer quelque chose d’incomplet, mais au plus vite • Apprendre par l’erreur • Doit accompagner des méthodes dites “agiles”
    27. 27. Cycle itératif
    28. 28. 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
    29. 29. RUP (Rational) Unified Process La première méthode liée aux concepts objets
    30. 30. 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
    31. 31. 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
    32. 32. 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
    33. 33. Fondement de RUP • RUP est : • Piloté par les cas d’utilisation • Centré sur l’architecture • Itératif et incrémental
    34. 34. 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 ?
    35. 35. 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
    36. 36. 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
    37. 37. 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
    38. 38. 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
    39. 39. 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
    40. 40. Exemple de use case
    41. 41. Exemple plus complet
    42. 42. 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…)
    43. 43. 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
    44. 44. Packages de use cases • Permet de simplifier des schémas de use cases • Utile dans le cas d’implémentation d’application métier
    45. 45. 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
    46. 46. 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
    47. 47. 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...
    48. 48. Notion de rôle • Ensemble d’activités et de responsabilités • Analystes • Développeurs • Testeurs • Managers
    49. 49. 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)
    50. 50. 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
    51. 51. 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 !
    52. 52. Phases d’un développement
    53. 53. 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
    54. 54. 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
    55. 55. 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
    56. 56. 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)
    57. 57. 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
    58. 58. 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
    59. 59. 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
    60. 60. 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
    61. 61. 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)
    62. 62. 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
    63. 63. eXtreme Programing La première des méthodes dites ‘agiles’
    64. 64. 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 » !
    65. 65. 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
    66. 66. Principes de base • Objectif : éviter le développement « cow-boy » • Principes : • Communication • Feed back • Simplicité • Courage • Peut être trop ‘militant’ ?
    67. 67. 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
    68. 68. 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
    69. 69. Cycle de développement XP
    70. 70. 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
    71. 71. 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
    72. 72. 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
    73. 73. 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
    74. 74. Petites livraisons • On limite au maximum la portée et l’importance d’une livraison • L’intégration continue doit faciliter cette tâche
    75. 75. 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
    76. 76. 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
    77. 77. 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
    78. 78. 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
    79. 79. 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 ?
    80. 80. 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
    81. 81. 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..
    82. 82. 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
    83. 83. 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...)
    84. 84. 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é
    85. 85. SCRUM Agilité et travail d’équipe
    86. 86. 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
    87. 87. 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
    88. 88. Les intervenants de Scrum
    89. 89. 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..)
    90. 90. 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
    91. 91. 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)
    92. 92. 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
    93. 93. 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)
    94. 94. 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
    95. 95. 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
    96. 96. 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
    97. 97. La Cathédrale et le Bazar Le modèle de développement du logiciel libre
    98. 98. 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
    99. 99. 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
    100. 100. 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
    101. 101. 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
    102. 102. 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
    103. 103. Boite à outils Utiliser le formalisme UML et divers autres outils dans la conduite de projets
    104. 104. 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
    105. 105. 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
    106. 106. 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’
    107. 107. 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
    108. 108. Tests Limiter la régression et aller vers une meilleure qualité du logiciel
    109. 109. 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
    110. 110. 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
    111. 111. 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
    112. 112. 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
    113. 113. 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
    114. 114. 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
    115. 115. 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
    116. 116. 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
    117. 117. 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”
    118. 118. 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
    119. 119. 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
    120. 120. Versions logicielles Maîtrise de l’évolution du software dans le temps
    121. 121. 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
    122. 122. Exemple de versioning • svn add list txt • svn ci list.txt -m “ajout a la liste”
    123. 123. Synchronisation serveur/ version locale • svn co list.txt • svn ci list.txt • svn revert list.txt • svn co -r2 list.txt
    124. 124. Comparaison deux fichiers • La commande diff permet de visualiser les différences entre deux fichiers • svn diff -r3:4 list.txt
    125. 125. Création d’une branche • svn copy http://...trunk http://....branch
    126. 126. Fusion de versions • svn merge -r5:6 http://...trunk
    127. 127. Tagging • svn copy http://...trunk http://...tag
    128. 128. Qualité De la conduite de projet vers la qualification des livrables
    129. 129. 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
    130. 130. 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
    131. 131. 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
    132. 132. Etat récapitulatif avec Sonar
    133. 133. Tests de montée en charge
    134. 134. Montée en charge avec JMeter
    135. 135. AntiPatterns L’apprentissage par l’erreur
    136. 136. 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
    137. 137. 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ù”
    138. 138. 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
    139. 139. 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
    140. 140. 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

    ×