Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas

Note : 6 ; Des conseils simples, avisés et … pragmatiques, pour bien commencer avec les tests unitaires.

Dans la veine des « starter kits » écrits par les « pragmatic programmers », voici un opuscule consacré aux tests unitaires en général et à JUnit en particulier. L’objectif est très clair : mettre le pied à l’étrier de manière pragmatique, sans s’encombrer de beaucoup de théorie. De fait le livre est court, avec 125 pages (hors annexes), mais quand même découpé en 9 chapitres, chacun étant donc court.
Le premier chapitre est une prose introductive au « pourquoi » des tests. Il s’étend largement sur les contre-arguments à leur écriture, et permet de balayer les objections les plus courantes. Toujours une bonne chose de faite. Au second chapitre, nous pratiquons l’équivalent du très classique « hello world ». C’est minimal et le chapitre est très court. Ce n’est pas le cas du chapitre 3 qui nous accoutume aux autres éléments utilisés classiquement lors de l’écriture de tests unitaires : setup, tear down, test suite et assertions en tout genre. Nous sommes armés pour écrire des tests plutôt standard mais qui répondent aux besoins courants.

A partir du chapitre 4, il est davantage question d’écrire de bons tests et une bonne couverture de test. Les auteurs proposent l’acronyme Right-BICEP. Tout d’abord il s’agit de définir ce qu’est un résultat juste, puis d’appliquer les règles du BICEP (que je ne vais pas développer ici). Toutefois le « B » pour boundary va être l’objet plus spécifiquement du chapitre 5 où il va être développé selon un autre acronyme, le CORRECT. Les conditions aux limites sont souvent source d’erreur, les auteurs font un bon travail à bien cerner l’ennemi. Le chapitre 6 est consacré aux Mock objects. Ce chapitre est juste une introduction au sujet, utilisant EasyMock, mais elle est consistante. Elle marque aussi la temporalité du livre, car l’exemple choisi est le mock d’une servlet !

Le chapitre 7 va aborder les propriétés d’un bon test et c’est l’occasion d’un nouvel acronyme : A-TRIP. Car si un test doit être Automatique, il doit aussi complet (Thorough) en testant ce qui peut casser, Répétable en remettant le système en conditions initiales en fin d’exécution, Indépendant en ne supposant pas de séquence d’exécution et enfin Professionnel ! Cette dernière propriété est énoncée de manière bien curieuse. Les auteurs veulent simplement dire que le code du test doit respecter les mêmes qualités de conception et d’implémentation que le code de production. Il n’y a guère de code au chapitre 8. Celui-ci est consacré à l’organisation du code de test et au cycle de développement. Rien que de très classique ici, puisque l’on organise le code façon Maven et que l’on préconise le test en continu sans toutefois aborder le TDD. Le livre se referme sur un chapitre 9 consacré à la conception, plus précisément aux implications du test unitaire sur la conception, ce que les auteurs appellent le « test-driven design ».

Continuer à lire « Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas »

Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner

Note 3 : Se retrouver à lire un livre que l’on n’a pas envie de lire…

Et ainsi donc, le développement itératif et incrémental est désormais acquis au développement agile ! Tout le développement itératif et incrémental ? Non ! Un village résiste encore et toujours : il s’appelle « spirale de Boehm ». Cet ouvrage est peut-être son chant du cygne, l’avenir nous le dira.

L’ouvrage que nous allons explorer nous présente l’ultime version du modèle en spirale. Il compte environ 250 pages découpés en 16 chapitres, eux-mêmes structurées en 4 parties. Si ces caractéristiques laissent présager une lecture pas trop longue et bien rythmée, c’est sans compter sur l’austérité de la prose ! Il est temps de s’y attaquer. L’introduction permet aux auteurs de positionner le « incremental commitment spiral model » que nous nommerons maintenant ICSM sur le même créneau des méthodes adaptatives que les approches agiles qui sont d’ailleurs citées. Elle ne cherche pas à s’y opposer, mais à se positionner différemment en s’appuyant sur 4 principes sur lesquels nous reviendront. Le but est de se tailler une place dans les environnements plus classiques et « legacy » qui sont quand même prêts à accueillir un cycle itératif. En prime, ce chapitre 0 nous propose une belle vue actualisée du cycle en spirale : l’ouvrage aura ainsi au moins une valeur archéologique !

La première partie compte 4 chapitres sur 80 pages. Ils vont détailler les 4 principes de l’ICSM que nous avons mentionné. Le premier chapitre aborde la question de la valeur pour les parties prenantes. Il s’appuie sur les leçons tirées de 2 histoires, notamment de la conception d’un équipement hospitalier. Ce principe est adossé au « success critical stakeholder » ou SCS. Ce principe est un mélange de modernité (la mesure du succès est le succès du SCS) et de choses plus anciennes avec une approche en phases qui rappelle étrangement Unified Process ! On n’échappe d’ailleurs pas à une matrice critères de succès / parties prenantes ! Au second chapitre, on aborde la notion d’engagement incrémental : c’est le cône d’incertitude qui est mis à l’honneur ici. Cette fois encore le propos est illustré de deux histoires, un succès et un échec, le succès étant le projet TRW débuté en 1978 qui fut à l’origine du cycle en spirale ! Le chapitre fait apparaitre l’approche comme très technocratique et la prose est plutôt lourde. Le volet intéressant de ce chapitre est la comparaison de modèles incrémentaux allant du « prespecified » au « evolutionary concurrent ».

Le 3ème principe que nous découvrons au chapitre 3 est le « concurrent multidiscipline engineering ». Nous avons aussi droit à deux histoires, celle illustrant le succès étant le développement d’un drone. Le propos est alambiqué et assez lourd. Il s’éclaire vers la fin du chapitre quand l’auteur nous déclare que l’utilisateur peut rarement spécifier clairement ce qu’il veut au début du projet et qu’il nous faut donc mener de front l’affinage des besoins, la conception et le développement. Il s’agit bien du fonctionnement multidisciplinaire que nous connaissons en agile. Il est simplement exprimé de manière obscure ici. Le dernier principe est celui des décisions basées sur les risques, le sujet du chapitre 4. Le propos se concentre sur la valeur apportée par les études de faisabilité. L’auteur met aussi en perspective l’approche de Walker Royce intégrée à Unified Process comme étant un progrès par rapport au cycle en spiral initial ! Globalement la coloration « pré-agile » y est assez évidente.

Continuer à lire « Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner »

Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg

Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

Continuer à lire « Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg »

Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood

Note 4 ; Informatif, mais pas passionnant.

Git, depuis son apparition est rapidement devenu le standard de fait de la gestion de version. Après avoir commis la gestion de version pragmatique avec CVS puis Subversion au début des années 2000, il devenait évident de proposer l’ouvrage équivalent pour Git. Équivalent il l’est car, comme nous allons le voir, il s’agit essentiellement d’une transposition du même texte au monde Git.

Le livre est plutôt court, avec 150 pages, mais découpé en petits chapitres, puisqu’il en compte 11, regroupés en 3 parties. La première partie est consacrée à l’installation et à la mise en œuvre initiale de Git. Le premier chapitre, c’est le tour du propriétaire. On y retrouve les concepts de base de la gestion de version, correctement actualisés par rapport à Git, mais sans exposer ses particularités outre mesure. Un bon chapitre pour les débutants sur la gestion de version, mais qui apporte peu pour les autres. Le second chapitre évoque l’installation et la configuration de base de Git. C’est vraiment du pas à pas pour différents systèmes d’exploitation, pas la peine de s’attarder. Avec le 3ème chapitre qui referme cette première partie, cela devient plus sérieux : il s’agit de créer un projet. En fait, on y fait même plus que cela : on y ajoute des fichiers et opérons quelques commandes de base. Le livre commence vraiment avec ce chapitre.

La seconde partie évoque l’utilisation de Git au quotidien. C’est la partie la plus importante de l’ouvrage, avec 6 chapitres sur 90 pages. Le chapitre 4 ouvre le bal avec les commandes de base, en allant plus loin que ce que nous avons vu au chapitre 3, c’est à dire créer de nouvelles versions, des branches, supprimer et renommer. Bref, tout ce que l’on peut faire individuellement sur un fichier. C’est bien écrit et décomposé : le débutant trouvera son bonheur pour bien débuter. La gestion des branches est un sujet qui arrive très vite, et c’est abordé au chapitre 5. De mon point de vue, sans couvrir toutes les possibilités, on va plus loin que les besoins quotidiens, avec le cherry picking et le renommage de branches. Le « merge manuel » est même abordé ! Étonnement, il n’y a pas trace du rebase !

Continuer à lire « Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood »

Note de lecture : Use Case Modeling, par Kurt Bittner & Ian Spence

Note 6 ; Cas d’utilisation & Unified Process !

Cela n’apparaît pas dans le titre, mais voici le livre officiel sur l’utilisation des cas d’utilisation dans le RUP. Cela explique, comme nous le verrons, une orientation de l’ouvrage clairement orientée vers le processus, plutôt que vers la modélisation. Le cadre est donc franchement prescriptif, mais aussi avec quelques avantages à ce positionnement : l’articulation avec d’autres éléments du processus.

Le texte en lui-même couvre 300 pages sur 12 chapitres. Quand on considère le thème, on peut considérer que c’est un ouvrage franchement volumineux. Mais les chapitres restent de taille raisonnable. Le tout est structuré en deux parties. La première couvre 145 pages pour 5 chapitres. Son objectif est de nous mettre le pied à l’étrier avec les cas d’utilisation. Le premier chapitre est la très classique introduction, destinée à nous permettre d’appréhender la place des cas d’utilisation au sein de la gestion des exigences. Le style est plutôt guindé, mais néanmoins efficace pour à la fois donner un peu de contexte Unified Process et évoquer les finalités des cas d’utilisation sans les trahir.

Le second chapitre s’attaque aux éléments fondamentaux des cas d’utilisation. En réalité il couvre bien tous les éléments nécessaires pour les mettre en œuvre à l’exception des éléments les plus exotiques. L’approche consiste en une déconstruction systématique des éléments méthodologiques : éléments du modèle, acteurs, flux d’évènements, mais aussi artéfacts support. Le tout hélas sans exemple et sans aborder le fond de ce que sont les cas d’utilisation au long de ces 30 pages. Bref, tout y est, sauf l’essence même des cas d’utilisation. Le chapitre 3 parle d’établir la vision, mais en fait le titre est un peu trompeur : il traite de manière plus générale de l’approche « feature » telle qu’elle est proposée par Dean Leffingwell dans « Managing the Requirements process ». Une approche une fois encore très orientée processus à tel point que les presque 40 pages du chapitre s’articulent en étapes ! Cette approche vient, en théorie, intersecter l’approche Cas d’Utilisation qui a une orientation plus comportementale. Dans la pratique, les deux approches ne se rencontrent guère ici. L’un des points forts de ce chapitre est l’étude minutieuse des parties prenantes et de leurs représentants.

Continuer à lire « Note de lecture : Use Case Modeling, par Kurt Bittner & Ian Spence »

Note de lecture : Pragmatic Version Control using Subversion 2nd edition, par Mike Mason

Note : 5 ; Une simple mise à jour.

Successeur de CVS, Subversion n’a pas encore complètement disparu du paysage, mais il est déjà un outil du passé. Cet ouvrage qui date du milieu des années 2000 nous rappelle qu’il n’en a pas toujours été ainsi. Cette seconde version couvre la version 1.3 de Subversion. Le texte grossit d’une dizaine de pages, et les annexes aussi, emmenant l’ensemble à 220 pages contre 200 précédemment. Le texte ne change guère sur le fond, il est juste annoté de quelques évolutions liées à la version 1.3 de subversion. L’esprit de cette série « starter kit » n’a pas changé : ni un manuel de référence, ni un guide de l’utilisateur, mais une manière de mettre en œuvre concrètement l’outil sur nos activités quotidiennes de développement !

Le texte principal compte à peine plus de 150 pages, structurés en 11 chapitres, auxquels il ne faut pas oublier d’ajouter pas moins de 70 pages d’annexes. Le texte s’ouvre sur un classique premier chapitre d’introduction. Il n’apprend pas grand-chose aux praticiens aguerris de la gestion de version, mais permet quand même d’évoquer quelques aspects particuliers à Subversion, tels que les changeset.

On attaque les choses sérieuses avec le chapitre 2 et les concepts essentiels de Subversion : repository, branches, tags, etc. ainsi que les actions classiques telles que check-in, check-out, merge ont au menu. Ce sont des fondamentaux clairement expliqués, mais nous ne sommes pas encore dans l’action. L’action, justement, elle commence au chapitre 3 où il faut installer l’outil, se familiariser avec la ligne de commande, créer repository et projet et mener à bien notre « hello world ». En réalité, on va un tout petit peu plus loin que le « hello world », mais si on a touché du doigt les commandes de base, on n’a pas encore travaillé en « grandeur réelle ».

Continuer à lire « Note de lecture : Pragmatic Version Control using Subversion 2nd edition, par Mike Mason »

Note de lecture : Multi-Paradigm design for C++, par James Coplien

Note : 3 ; Un livre décevant, échouant sur C++ et sur la méthode.

Le titre de l’ouvrage était prometteur : C++ est le langage multi-paradigmes par excellence. Le livre de Bjarne Stroustup sur le langage commence même par une phrase en faisant mention. Et j’avoue que concevoir des structures intégrant objet, types abstrait des données et templates est l’un des exercices que je trouve le plus stimulant avec ce langage. Bref, j’avais des attentes assez élevées concernant cet ouvrage. Elles ont été un peu douchées.

Avec 260 pages découpées en 9 chapitres, le texte n’a pas un abord inquiétant, il promet même un rythme de lecture assez soutenable avec des chapitres pas trop longs. Le premier chapitre, avec ses 27 pages introduit justement cette question du multiparadigme et l’erreur de casting va commencer à apparaitre. L’auteur y évoque les variabilités et les « commonalités » ainsi que du domaine de l’analyse et du domaine de la solution. L’auteur s’y perd quelque peu et nous perd encore plus. Tout cela ne commence pas bien.

L’identification des commonalités dans le domaine de l’analyse est le sujet du chapitre 2. Après la confusion du premier chapitre les choses semblent plus claires ici : c’est la recherche des dénominateurs communs dans les concepts de l’application. J’ai l’impression de revivre les temps d’OMT (même si UML était déjà là et bien là en 1999). En fait l’auteur se prévaut de références plus anciennes : David Parnas et Ed Yourdon, donc datant des années 80 voir avant ! La tentative d’accoster du code C++ à cela parait bien poussive.C’est au tour de la variabilité d’être investiguée au chapitre 3. L’auteur y distingue différents types de variabilité, qui s’expriment dans le langage avec différents « binding times ». L’idée est intéressante et originale. Ainsi l’auteur décline ces différents binds : à la compilation avec la compilation conditionnelle, au link avec les templates et bien sûr à l’exécution avec les méthodes virtuelles. La projection du volet conceptuel vers le volet technique est hélas moins clair.

Continuer à lire « Note de lecture : Multi-Paradigm design for C++, par James Coplien »

Note de lecture : Pragmatic Version Control using CVS, par Andrew Hunt & David Thomas

Note : 6 ; “Best practices” et utilisation de CVS parfaitement intégrés.

Quand les Pragmatic Programmers » ont décidé d’ouvrir boutique en devenant éditeurs, ils ont commencé par publier des « starters kits » destinés à permettre l’utilisation d’outils labellisés « pragmatiques » avec les recettes agiles qui vont avec. Le roi de la montagne des gestionnaires de version était alors Subversion, mais CVS (qui nous intéresse aujourd’hui) était encore utilisé, tandis que Git n’était pas encore né. Peu de monde se souvient encore du successeur de RCS (dont encore moins de personnes se souviennent), et ce guide pratique va nous permettre de le maitriser au quotidien. Bien sûr aujourd’hui le texte a d’avantage un intérêt historique, voir archéologique.

L’ouvrage ne pèse gère lourd avec moins de 140 pages auxquelles il faut ajouter une quinzaine de pages d’annexes. Le tout est structuré en 10 chapitres. Le premier chapitre cueille bien tôt le développeur débutant pour lui faire appréhender l’intérêt d’un gestionnaire de version, au travers d’une courte histoire. Quelques pages qui ne seront utiles qu’au grand débutant. Le second chapitre attaque les choses sérieuses, avec les concepts gravitant autour de la gestion de configuration, et surtout les cas d’usage de ce type d’outil : branche de développement, bug fixes, conflits, etc. Le tout bien illustré et expliqué efficacement. Le tout reste générique, sans aborder les spécificités de CVS.

C’est au chapitre 3 que l’on attaque véritablement la prise en main de CVS, depuis l’installation, jusqu’au gestes de base évoqués au chapitre précédent, en passant par la configuration et la gestion de projet. Les lignes de commande sont développées et expliquées, comme on peut s’y attendre de ce type d’ouvrage. Ces 3 premiers chapitres étaient en quelque sorte l’introduction. Je passe sur le chapitre 4 qui est en quelque sorte le préambule du reste du livre.

Continuer à lire « Note de lecture : Pragmatic Version Control using CVS, par Andrew Hunt & David Thomas »

Note de lecture : Patterns for Effective Use Cases, par Steve Adolph & Paul Bramble, with Alistair Cockburn & Andy Pols

Note: 7 ; Un (excellent) complément au « Writting Effective Use Cases » d’Alistair Cockburn.

Les cas d’utilisation sont un peu passés de mode depuis la grande époque UML, jusqu’au début des années 2000. C’est bien de cette époque que date cet ouvrage dont on peut pourtant dire qu’il serait injuste de le considérer comme passé de mode ! Il s’inscrit dans la lignée du « writting effective Use Cases » d’Alistair Cockburn qui promeut une écriture intentionnelle, courte et efficace par rapport aux Cas d’Utilisation « interactionnels » qui noircissent beaucoup de pages et ont donné une image si déplorable de cette pratique.

L’ouvrage a adopté le forme « Pattern Language ». Elle n’est pas toujours appropriée pour un livre d’environ 200 pages, mais on doit bien constater qu’ici cela ne pose guère de problème. Ceux-ci sont partitionnés sur 7 chapitres (auxquels il faut ajouter le chapitre introductif). Chaque pattern occupant environ 6 à 8 pages, donc assez pour être développé et pas trop pour ne pas devenir indigeste. Le premier chapitre investigue ce qu’est réellement un cas d’utilisation de qualité. C’est du moins la promesse faite par ce chapitre dont le titre est un peu trompeur. Si les auteurs nous montrent effectivement ce qu’est un bon Cas d’utilisation par rapport aux mauvais cas d’utilisation (toute ressemblance avec les bons et les mauvais chasseurs…), le chapitre sert surtout de table de matière et au langage de patterns et d’introduction à la forme pattern. Cela dit, il n’y a rien de mal à cela et c’est même nécessaire.

Le chapitre 2 nous prend un peu par surprise : « The Team » évoque les aspects collaboration et coopération gravitant autour de l’écriture des cas d’utilisation ! Ainsi, ParticipatingAudience met l’accent sur l’implication des utilisateurs et des parties prenantes, tandis que BalancedTeam détaille la pertinence de former des groupes d’écriture diversifiant les points de vue. En réalité, les éléments évoqués sont un peu des nouvelles d’hier, mais les expliciter ne peut pas faire de mal. Le chapitre 3 « The Process » s’inscrit dans la continuité. Le chapitre est assez riche et ne commet pas l’erreur de proposer un workflow de rédaction. BreathBeforeDepth est sans doute l’un des patterns cruciaux de ce chapitre. Les auteurs y référencent de très nombreux autres patterns, sans doute trop. Mais le propos est crucial pour la réussite d’une démarche « cas d’utilisation ». Je suis plus surpris d’y trouver TwoTierReview qui aurait d’avantage eu sa place dans le chapitre précédent, à mon avis. Le QuittingTime est une bonne idée : il rappelle que « pas trop n’en faut » et qu’ajouter du détail peut être contre-productif. C’est une mise en garde dont j’ai eu à faire bon usage, car je dois avouer avoir été coupable de ce travers !

Continuer à lire « Note de lecture : Patterns for Effective Use Cases, par Steve Adolph & Paul Bramble, with Alistair Cockburn & Andy Pols »

Note de lecture : Gestion de Configuration : Maîtrisez vos changements logiciels, par Linda Djezzar

Note: 6 ; Une très bonne introduction aux processus de gestion de configuration, même si elle me laisse un peu sur ma faim.

Cet ouvrage fort digeste est destiné à faire comprendre ce qu’est la gestion de configuration, ses enjeux, sa mise en œuvre et ses apports. En ce sens, le livre est avant tout destiné aux managers. Comme nous allons le voir, il fait quand même l’effort de s’ancrer dans la réalité des outils de gestion de configuration, on pourrait presque dire qu’il s’agit d’un ouvrage hybride !

Justement, jetons un coup d’œil au texte. Tout d’abord, il est court avec ses 140 pages, ce qui renforce son ancrage vers les managers (quoique pour eux, même cela commence à être long…). Le texte est rythmé en 9 chapitres, ce qui constitue une taille moyenne assez réduite pour chaque chapitre. J’aime bien. Pour structurer encore plus, malgré la taille réduite du texte, les chapitres sont regroupés en 3 parties. La première d’entre-elle, « l’état de l’art », est constituée de 3 chapitres sur une cinquantaine de pages. Et l’on va commencer à explorer les concepts de base au premier d’entre-eux, sur une douzaine de pages. Après un trop court éclairage historique, on rentre directement dans un ensemble de définitions, certes rébarbatives, mais que l’auteure arrive à rendre digestes. Finalement, c’est la fin du chapitre qui serait la plus intéressante, mais les fonctions de la gestion de configuration sont traitées bien succinctement…

Même s’il ne compte qu’une quinzaine de pages, le second chapitre reprends là où le premier nous avait laissé en plan : les fonctions de la gestion de configuration. Bien sûr, on ne peut pas dire que le panel d’outils évoqués respire la modernité (CVS, PVCS, Clear Case…), ni que l’inscription dans le cycle de travail soit d’inspiration agile, mais il ne faut pas oublier que le texte date du début des années 2000 et au moins l’illustration est bien ancrée dans la réalité du cycle de développement. Le 3ème chapitre va donner à manger aux managers et aux cellules qualité avec l’évocation des modèles de maturité. Ce n’est pas le meilleur moment du livre.

Continuer à lire « Note de lecture : Gestion de Configuration : Maîtrisez vos changements logiciels, par Linda Djezzar »