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

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

19. En cascade

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

22. Cycle en V

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 ;)

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”

28. Cycle
itératif

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

41. Exemple de use case

42. Exemple plus complet

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

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 !

54. Phases d’un
développement

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

71. Cycle de développement
XP

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

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é

88. SCRUM
Agilité et travail d’équipe

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

91. Les intervenants de
Scrum

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

135. Etat récapitulatif avec
Sonar

136. Tests de montée en charge

137. Montée en charge avec JMeter

138. AntiPatterns
L’apprentissage par l’erreur

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