Note de lecture : The Rational Unified Process, an introduction, 3rd edt., par Philippe Kruchten

Note : 6 ; Une importante revue de l’ouvrage

Rational Unified Process fut la méthode tendance jusqu’au milieu des années 2000. Cette 3ème édition est en quelque sorte la mouture ultime (en attendant sa renaissance dans les années 201x, sous le nom de SAFe). Chaque workflow de RUP est riche de descriptifs, de rôles et de pratiques, au point que chacun d’entre eux nécessite au moins un ouvrage pour couvrir le sujet. Ici, il s’agit plutôt d’un tour d’horizon de l’ensemble de ces workflows.

Contrairement à l’édition précédente qui ne représentait qu’une évolution mineure de livre (et du processus), celle-ci a fortement évolué, gonflant également l’édition d’une bonne quarantaine de pages, pour un total de 270 pages hors annexes. Le tout est divisé en deux parties inégales. La première compte 110 pages sur 6 chapitres et traite du processus dans sa globalité. Le premier chapitre est certainement particulier, car il traite de la notion de « best practices », mais surtout il est signé Grady Booch. Après une courte introduction sur cette notion de best practices et de développement itératif et incrémental, l’auteur nous évoque les propriétés d’un bon processus : gestion des exigences, modélisation visuelle, gestion du changement, etc… Bref, les propriétés mises en avant par RUP (ou UP).

Le second chapitre fait écho à ce premier chapitre en déclinant les propriétés évoquées sur RUP, puis en évoquant la structure en 2 dimensions du framework. Tout cela se lit facilement mais il est clair que l’on n’est pas rentré dans le vif du sujet. Le chapitre 3 reste très abstrait car il décrit le méta-modèle du framework : rôles, artéfacts, activités (et étapes d’activités), workflows et disciplines ! Les couches de « pilotage » que sont les guidelines et autres templates ne sont que brièvement décrits. L’ensemble revêt une certaine esthétique pour l’académicien ou le théoricien (moi par exemple) mais va sembler austère et très abstrait pour qui ne porte pas un intérêt aiguisé aux processus de développement !

Lire la suite

Note de lecture : More effective C++, par Scott Meyers

Note : 9 ; De la même veine et de la même qualité que le 1er volume

Effective C++ fut indéniablement un succès. La formule a depuis été reprise par d’autres auteurs, empruntant souvent la même qualité de pertinence technique. Mais ces autres textes n’ont pas la verve d’un Scott Meyers ! Ce second volume est de la même eau que le premier. Ici les centres d’intérêts se focalisent sur un certain nombre de sujets précis (exceptions, casts, etc…) et l’auteur développe plus son propos. D’ailleurs le nombre de règles est plus réduit, tandis que le nombre de pages a augmenté, passant à 290 pages.

L’auteur a structuré son propos en 6 thèmes. Les « basiques » couvrent 4 items plutôt simples sur une quinzaine de pages. La seule « nouveauté » étant les cast C++ apparus depuis peu (à l’époque). La seconde partie couvre aussi 4 items, cette fois sur une vingtaine de pages et sur un sujet plus particulier : les opérateurs. Outre les subtilités dont l’auteur nous régale comme à son habitude, je relève ici deux items particulièrement importants : les écritures idiomatiques des opérateurs pré et post incréments, et les différentes formes des opérateurs new et delete.

La troisième partie nous conduit vers un sujet délicat avec les exceptions : 7 items leur sont dédiés sur 35 pages. Ici, il s’agit tout au long de ces items de nous faire prendre conscience des implications et des limites de leur usage : fuite de mémoire, contraintes au sein des constructeurs et des destructeurs, impact sur les performances, etc. Il y a de quoi s’enfuir, ce qui n’est pas le propos de l’auteur.

Lire la suite

Note de lecture : The Unified Process Transition and Production Phases: Best practices in implementing the UP, par Scott W. Ambler & Larry L. Constantine

Note : 3 ; Un quatrième opus de la suite dédie à UP, d’avantage cohérent avec le sujet

Dernier opus de la série consacrée à Unified Process, celui-ci reprend la formule qui nous a tellement enchantée dans les volumes précédents. Celui-ci est fort de 280 pages et compte 8 chapitres, introduction et conclusion incluses. L’introduction, justement, est le seul chapitre réellement écrit pour correspondre au titre de l’ouvrage. Il compte une douzaine de pages et cherche à replacer chaque workflow dans le contexte de la phase de transition.

Le second chapitre va couvrir 35 pages et se focalise sur le workflow de déploiement. Il compte 6 articles dont 3 sont signés Scott Ambler (l’éditeur de l’ouvrage si vous avez suivi). Contrairement aux ouvrages précédents, la plupart de ces articles ont effectivement trait au déploiement et au rollout en phase de transition. Leur lecture nous laisse apparaitre le chemin parcouru depuis lors grâce au mouvement devops !

Le chapitre 3 traite du workflow « tests », et ce ne sont pas moins de 8 articles que nous retrouvons là ! Cem Kaner nous parle du recrutement de testeurs. Cela a peu à voir avec la phase de transition, mais non seulement l’idée est intéressante, mais on y trouve beaucoup de matière pertinente. Dans la même veine, James Bach évoque la formation des testeurs. Le propos mériterait toutefois d’être actualisé. Dans le style nostalgie, McGregor & Major nous parlent de « maximiser le ROI en sélectionnant les cas de test » ! Voilà une pensée définitivement issue de l’ancien monde ! Plus original, « don’t waste your bugs ! » nous propose une analyse qualitative des bugs pour estimer la maturité du code ! Le worflow « Project Management » est au menu du chapitre 4 et nous propose 6 articles. Bien qu’ils aient peu à voir avec le sujet, « making lemonade with lemon » aborde les besoins psychologiques des équipes. Un des rares écrits de Norman Kerth, donc à ne pas rater. « Looking back » est co-signé par Karl Wiegers et Johanna Rothman ce qui est en soi une raison de s’y arrêter. L’autre est que l’on y décrit la démarche de rétrospective.

Lire la suite

Note de lecture : The Unified Process Elaboration Phase, par Scott W. Ambler

Note : 2 ; Une compilation bien hétéroclite !

Tout comme le volume dédié à la phase « d’inception », ce volume regroupe un ensemble d’articles en provenance de Software Développement Magazine. Ils sont globalement organisés en worflows, ce qui nous donne 8 chapitres (en comptant introduction et conclusion), pour un total de 260 pages hors annexes.

Le premier chapitre est purement introductif. Il met en contexte le processus itératif par rapport aux processus en cascade et donne un aperçu des différents workflows, puis plus précisément de la phase d’élaboration. Tout cela ressemble pas mal au premier chapitre du volume consacré à la phase d’inception. Cela reste aussi très général. Place au workflow « Project management » au chapitre 2, qui va regrouper 6 articles. J’en retiens essentiellement deux : « managing collaborations » par Mary Loomis évoque les propriétés essentielles du cadre pour rendre possible cette collaboration. « implementing feature teams » par Jim McCarthy préfigure les équipes pluridisciplinaires que l’on retrouvera dans le fonctionnement agile. Aucun des 6 articles n’est lié à la phase d’élaboration ni même à Unified Process.

Le chapitre 3 aborde le workflow « business modeling” et ce sont 4 articles qui sont mis en avant ici. Malgré la présence d’un article de Martin Fowler, aucun d’entre eux ne retient mon attention. Ce workflow semble décidément une source d’embarras à décrire… Nous arrivons maintenant au chapitre 4 qui va évoquer le workflow de gestion des exigences. Nous avons 5 articles ici. Karl Wiegers nous offre toujours une prose de qualité et « Writing Quality Requirements » s’inscrit dans cette mouvance. Je garde. Puis « Prototyping from the User’s Viewpoint » est un des rares articles qui cadre vraiment avec la phase d’élaboration d’UP. Je garde également !

Lire la suite

Note de lecture : Java Beans : Guide du programmeur, par Robert Englander

Note : 6 ; Voyage tranquille au temps des Java Beans

Les Java Beans sont un sujet des premiers temps de Java, il en est devenu désuet. Alors que JEE était en train de promettre aux oubliettes ce fier modèle de composant, Spring lui aura offert une seconde jeunesse. Par un étrange trait du destin, c’est JEE qui se sera offert son ticket pour le musée d’archéologie !

Bien que le sujet soit assez basique, Robert Englander nous aura produit un ouvrage de 260 pages ! Celui-ci compte 10 chapitres que nous allons explorer. Le premier chapitre nous propose sur une dizaine de pages un tour d’horizon des propriétés des Java Beans, mais sans réellement rentrer dans ce qu’ils sont réellement. C’est assez superficiel. Beaucoup plus sérieux, le second chapitre explore en profondeur le modèle d’évènements des Java Beans. Passé de mode (et je suis gentil), ce chapitre est l’un des intérêts de ce texte vieux de plus de 20 ans. D’autant que le sujet est traité de manière exhaustive et avec pédagogie. Je regrette juste que ne soit pas adressé la représentation interne et le mécanisme de dispatching de ces évènements. Oh nostalgie, le chapitre se termine par AWT (paix à son âme) grand consommateur d’évènements Java Beans.

On continue sur le thème des évènements au chapitre 3, avec les adaptateurs d’évènements (qui sont en fait des listeners) et une pincée de réflexion pour rendre cela générique. Et toujours la déclinaison AWT en fin de chapitre. Eh oui, en 1997, c’était important. Le chapitre n’est pas grandiose, mais bien expliqué et bien illustré. Place aux propriétés au chapitre 4. Le chapitre est assez exhaustif sur la question, avec entre autres les évènements de changement de propriétés.

Lire la suite

Note de lecture : The Unified Process Inception Phase, par Scott W. Ambler & Larry L. Constantine

Note : 2 ; Pratiquement le désappointement annoncé !

Autant prévenir tout de suite, ce livre est une compilation d’articles parus dans « Software Development », ce qui peut expliquer l’aspect quelque peu hétéroclite de l’opuscule. L’intérêt des textes eux-mêmes est assez variable et va de passable à intéressant.

Les 280 pages de ce volume sont structurées en 7 chapitres qui sont autant de thèmes. Chaque chapitre rassemble lui-même plusieurs articles. Aucune originalité dans le premier d’entre-eux qui s’intitule sobrement « introduction ». Pour me faire mentir, ce chapitre-ci n’est pas une compilation d’article, mais une introduction, à Unified Process d’abord et à la phase d’inception ensuite. Ce n’est pas mal du tout en fait.

On rentre dans le dur au second chapitre « Best practices for business modeling » qui rassemble 5 articles sur 45 pages. A part peut être l’article consacré aux cartes CRC, les autres donnent vraiment l’impression d’être rentrés aux forceps dans ce thème. Le pire étant je pense la présentation d’UML par Scott Ambler qui n’a pas grand-chose à voir avec la choucroute. Si les contributeurs ont du mal à comprendre ce qu’est la modélisation métier, cela s’arrange au chapitre 3 consacré aux exigences. Et cela commence même très bien avec l’article d’Ellen Gottesdiener dédié au décodage des besoins métier. J’approuve aussi l’article suivant qui clame les droits du client, signé par Karl Wieger. L’article sur le JAD et les règles métiers méritent aussi une mention. Finalement seul le papier de Scott Ambler (encore lui) finira dans la corbeille du même nom.

Lire la suite

Note de lecture : Les JSP, par Eric Chaber

Note : 2 ; Un peu d’arnaque à l’horizon

Eh bien oui : je cherchais un texte assez simple et facile d’accès pour écrire quelques pages JSPs, juste de quoi me faire de l’auto-formation. Un livre ne français m’était apparu être un bon choix. Ce ne fut pas le cas, nous allons voir pourquoi.

L’ouvrage est assez modeste avec ses 190 pages sur 10 chapitres. Cela commence vraiment très bas avec les deux premiers chapitres. Certes ils sont courts, mais je ne m’attendais pas à ce que moi lecteur je sois pris aussi bas qu’une explication sur le langage java s’impose… Par comparaison, les 20 pages du troisième chapitre paraissent costauds, surtout que l’on passe en un clin d’œil de la présentation de Java EE aux JSP. Au moins, même s’il ne fait pas rêver, ce chapitre nous montre-t-il les fondements des JSP !

Place au chapitre 4 … et à la connexion aux bases de données. Car l’auteur fait tout depuis les pages JSP, y compris du code JDBC. La mise en tableau des résultats fait partie du package, on s’interrogera juste sur la pertinence du design… Le chapitre 5 est court et nous permet de reprendre notre souffle. Il traite exclusivement des cookies. Au chapitre 6 on attaque du lourd avec les Java Serveur Tags. Malheureusement, ce chapitre ressemble surtout à un manuel de référence où l’auteur nous dispense de temps à autre (visiblement à contrecœur) quelques exemples. Bref, passons.

Lire la suite

Note de lecture : Camel in Action, par Claus Ibsen & Jonathan Anstey

Note : 7 ; La qualité des grands classiques “in action”

La série « in action » chez Manning est en principe une recette éprouvée. Elle doit permettre de rencontrer des ouvrages solides, dont les sujets sont bien abordés de manière progressive et illustrée en se salissant les mains. Malheureusement trop de titres échouent aux portes des critères qualité. Rien de tout cela ici. Le texte est solide, abondement pourvu d’illustrations (parfois trop, certaines ne servent à rien) et d’exemples de code.

Camel est un framework recelant de nombreuses facettes, parfois insoupçonnées. Les auteurs les abordent de manière systématique avec un bon niveau de profondeur. Voyons cela. D’abord ce volume nous assène 460 pages hors annexes. Sérieux me direz-vous ? La seconde édition sortie depuis accuse elle dans les 900 pages ! Revenons à celle-ci. L’ensemble est structuré en 3 parties pour un total de 14 chapitres. Oui, cela signifie donc des chapitres plutôt conséquents.

La première partie « first steps » est aussi la plus courte : moins de 60 pages avec seulement deux chapitres. La première partie « Meeting Camel » nous permet de faire le tour du propriétaire et de découvrir notre premier « hello world » de manière très agréable. C’est aussi l’occasion de faire connaissance avec les concepts de base de Camel. Les Enterprise Intégration Patterns (EIP) sont même évoqués mais sans plus. Coup de zoom au second chapitre « Routing with Camel » qui va en fait assez loin dans les différents concepts de routage, allant jusqu’au multicast ! L’étude de cas abordée ici n’est pas utilisée au fil de l’ouvrage de façon mortelle, mais au moins sert-elle de point d’ancrage. Les auteurs switchent aussi beaucoup entre le « Java DSL » et le « Spring DSL » allant jusqu’à utiliser le Java DSL avec Spring (en fait leur cocktail préféré ». Cette bascule permanente permet certes d’aborder de manière exhaustive les deux manières de faire sur tous les sujets mais est aussi assez fatigante.

Lire la suite

Note de lecture : Corba : des concepts à la pratique, 2nd édition – Jean-Marc Geib, Christophe Gransart & Philippe Merle

Note : 6 ; Une présentation plutôt pédagogique, mais un texte qui accuse son âge.

Comme le titre l’indique, l’objet de ce livre est d’expliquer Corba en commençant par les principes, puis en poursuivant par la pratique. De fait, le texte devrait pouvoir servir de support d’un cours Corba, par exemple.

Les deux premiers chapitres sont un tour d’horizon des principes de Corba. En une cinquantaine de pages, on fait le tour des concepts de ce middleware, le tout agréablement soutenu par des diagrammes. Pas mal. Curieusement, c’est par une investigation en profondeur que l’on continue, que l’on a un peu de mal à raccrocher à la partie précédente. L’auteur a dû juger que cela était un prérequis indispensable aux chapitres suivants : les interfaces standard de Corba (chapitre 4), hélas fort peu illustré par un exemple pratique, puis les services standard (chapitre 5), toujours aussi peu soutenu d’exemple, même si les diagrammes sont valables. Nous voici arrivé en page 180 (sur 265, hors annexes), avec une vue consistante de Corba, mais peu d’exemples.

C’est le chapitre 6 qui constitue l’étude de cas venant illustrer les parties précédentes. Celui-ci aide pas mal pour comprendre l’implémentation d’un objet Corba en BOA, ainsi que l’utilisation du service de nommage, hélas de nombreux concepts précédemment illustrés n’apparaissent pas, comme les différents types de services décrits.

Lire la suite

Note de lecture : Réussir la conduite de projets informatiques, par Pham Thu Quang & Jean-Jacques Gonin

Note : 3 ; Les bases de la gestion de projet à la papa. Assez léger.

Il fut un temps où, croyant fermement que mon avenir était de devenir chef de projet, je voulais réellement savoir en quoi cela consistait, figurant vaguement que cela avait à voir avec la planification. C’est bien cette approche à la papa que couvre cet ouvrage. Hop, c’est parti pour 170 pages divisé en 3 parties totalisant 14 chapitres.

La première partie n’occupe que 25 pages et 2 chapitres et s’intitule pompeusement « conduite de projets d’informatisation ». Elle commence par un chapitre ultra-court de 4 pages pour distinguer système informatique et système d’information ! A la lumière d’une décennie et demie d’agilité, le second chapitre sur les raisons de l’échec laisse rêveur : absence d’une démarche, besoins insuffisamment exprimés ou changeants… Cela présage bien pour la suite !

La suite, c’est la seconde parties « techniques et démarche de la conduite de projet ». Près d’une centaine de pages et 8 chapitres, c’est la plus longue partie. Le chapitre 3 nous parle de démarche, donc de « cycle en V ». On notera le petit paragraphe sur la partie développement « considérée triviale par certains mais tout de même importante » ! Le chapitre se fend de plans-type des documents important. Pour ce qui est d’un texte sur le cycle en V, j’ai vu bien pire ! Le chapitre 4 est celui qui m’a fait acquérir le livre à l’époque : le diagramme de Gant expliqué ! Oui, vous avez bien lu ! Le fait est qu’il est très bien expliqué. Le chapitre 5 traite quand à lui de l’estimation des charges. Il traite à part égale les points de fonction et le COCOMO. Les auteurs ne s’étalent pas en longueur et le texte ne saurait servir de référence sur l’un ou sur l’autre, il n’en est pas moins ennuyeux.

Lire la suite