Discussion :

[Gordon Fowler]

L’ALM trop mal connu, d’après Borland
Même si la gestion du cycle de vie des applications sera de plus en plus présente en 2013

L’éditeur Borland (Micro Focus) vient de faire le point sur le marché de l’ALM (Application Lifecycle Management) dans une étude qu’il promet de renouveler chaque année pour en faire un baromètre des outils de gestion de cycle de vie des applications.

Le premier enseignement est que l’ALM serait mal connu. « Fin 2012, l’ALM n’est toujours pas un sujet familier pour 57% des répondants à l’étude », constate Borland qui définit la discipline par la voix de Frédéric Miche, son Architecte Solutions, comme « l’ensemble des bonnes pratiques pour atteindre la meilleure efficacité des applications malgré l’empilement de couches technologiques successives et la complexification des schémas ».

Le marché de ces solutions est dominé par les offres de 5 grands éditeurs : IBM (Rational), HP (et Mercury), Microsoft (Visual Studio avec Team Foundation), Borland et Serena. « Cette connaissance des solutions est toutefois à pondérer car 40% des répondants associent l’ALM à des solutions open source », constate Micro Focus.

Dans ce contexte concurrentiel, Borland ne cache pas son objectif avec ce baromètre : se faire connaitre et reconnaître.

La gamme de solutions ALM de Borland

Si l’ALM est mal connu, il susciterait paradoxalement de nombreuses attentes auprès des professionnels.

Pour Frédéric Miche « les développeurs passent environ 40% de leur temps à refaire des choses qui ont été mal faites ou qu’il faut faire évoluer ».

Ce qui explique les aspirations et les exigences autour de ces solutions. « Malgré cette méconnaissance, 43% des répondants ont budgété pour les 6 à 12 prochains mois un projet ALM. Ils reconnaissent en effet l’importance d’améliorer la qualité du processus de développement logiciel et visent trois principaux bénéfices à travers la mise en œuvre d’une démarche ALM : améliorer la satisfaction des utilisateurs, accroître la qualité des livrables, favoriser une plus grande collaboration entre développeurs ».

Autre facteur qui pousse les professionnels à regarder l’ALM de plus près : l’accélération des cycles de développement.

Les réalisations de plus en plus courtes obligent à gérer les mises à jour de manière plus intensive et, en parallèle, à améliorer la productivité des équipes. Deux objectifs que vise également l’ALM.

Enfin les environnements de développement de plus en plus hétérogènes (Java, .Net, technos Web, ERP, Mainframes, etc.) pousseraient également à devoir gérer cette complexité grandissante avec des solutions dédiées.

Bref, "l’ALM on ne connait pas (ou peu) mais on a des attentes", pourrait-on résumer en une phrase.

Des attentes et des projets donc, puisque « 43% des répondants affirment avoir des projets de démarche ALM », selon l’étude. Sur ces 43%, plus de la moitié (26%) l’envisagerait même sur l’année à venir.

Ceci dit, l’ALM ne concerne pas tout le monde.

C’est un autre enseignement de cette étude : les outils de gestion de cycle de vie des applications sont le plus souvent déployés dans de grosses voire très grosses structures. Plus de la moitié des répondants possèdent des départements informatiques de plus de 50 personnes et consacrent au développement des budgets supérieurs à 1 million d’euros.

Dernier enseignement, les projets étant de plus en plus gérés en externe, de plus en plus de tâches combinent des ressources internes et externes avec des SSII et des intégrateurs.

Une nouvelle donne qui fait que « gérer le cycle de vie des applications est un sujet de préoccupation montant chez les DSI qui […] ont besoin d’adapter les SI en continu », conclut Frédéric Miche. « Recourir à des approches qui structurent les développements logiciels est un atout pour suivre le rythme accéléré de ces changements sans dégrader la qualité des applications métier, ni dépasser les budgets ».

Frédéric Miche, Micro Focus / Borland

Source : Developpez.com, conférence de presse 09/01/2013

Et vous ?

Utilisez-vous des solutions pour gérer le cycle de vie de vos applications ?
Si oui lesquelles, pour quels objectifs et avec quels résultats ?

[souviron34]

Je pense surtout, comme je l'avais signalé lors de la modification du titre de ce forum, que changer l'appellation de quelque chose de bien connu de tous acteurs du développement en informatique pour un acronyme ou des termes nouveaux recouvrant grosso-modo la même chose est un truc marketing, et qu'il ne faut donc pas s'étonner du peu d'écho...

Contrairement à ce que semble penser Borland, la notion de Lifecycle, de Lifecycle Management (c'est bien le cas de toutes les méthodlogies de développement existantes, non ??), et ce qui y est associé est très ancienne et très bien implanté chez la plupart des acteurs du mileiu....

Il n'est donc pas étonnant du tout qu'un nouveau "buzz-word" recouvrant les mêmes notions reste très mal connu voire (très) peu intéressant...

[tetanos]

Franchement, si un logiciel est bien spécifié, bien codé avec des tests unitaires avec une couverture proche de 100%, est-il nécessaire d'investir dans de tels outils?

La nécessite d'investir dans de tels outils n'est-il pas un indicateur d'une mauvaise conception logicielle, d'une mauvaise pratique de développement, ou simplement d'une surcharge chronique de l'équipe de développement?

[el_slapper]

Je pense surtout, comme je l'avais signalé lors de la modification du titre de ce forum, que changer l'appellation de quelque chose de bien connu de tous acteurs du développement en informatique pour un acronyme ou des termes nouveaux recouvrant grosso-modo la même chose est un truc marketing, et qu'il ne faut donc pas s'étonner du peu d'écho...

Contrairement à ce que semble penser Borland, la notion de Lifecycle, de Lifecycle Management (c'est bien le cas de toutes les méthodlogies de développement existantes, non ??), et ce qui y est associé est très ancienne et très bien implanté chez la plupart des acteurs du mileiu....

Il n'est donc pas étonnant du tout qu'un nouveau "buzz-word" recouvrant les mêmes notions reste très mal connu voire (très) peu intéressant...

J'avais pris -7 et une soufflante des admins pour avoir tenu un discours similaire. Sans regret, "ALM", c'est juste un mot que pas grand monde ne connait.

Ca ne veut pas dire que le sujet est sans objet. La gestion de sources, ça fait partie du cycle de vis logiciel, et donc de l'ALM, et c'est indispensable dès qu'on a plus d'un programmeur sur la vie de l'appli. Déjà, quand on est seul, ça peut servir.

La modélisation, on en fait parfois trop, mais c'est quand même souvent utile(ne serait-ce qu'a posteriori pour expliciter la solution qui marche). C'est de l'ALM. C'est même les 3/4 du forum ALM.

Enfin, "des tests unitaires proches de 100%", moi l'ancien homologateur, ça me fait bondir. Certes, les tests unitaires sont indispensables. Mais c'est seulement quand on met les unités ensemble avec des données réalistes qu'on sait si ça marche. Sans compter l'utilisateur bourrin qui tape sur le clavier pendant deux heures, juste pour le plaisir de faire péter l'appli, ou encore les tests de charge. Les tests unitaires, c'est important, mais c'est très insuffisant pour s'assurer que l'appli est de qualité professionelle.

[souviron34]

La nécessite d'investir dans de tels outils n'est-il pas un indicateur d'une mauvaise conception logicielle, d'une mauvaise pratique de développement, ou simplement d'une surcharge chronique de l'équipe de développement?

Tout à fait..

J'avais pris -7 et une soufflante des admins pour avoir tenu un discours similaire. Sans regret, "ALM", c'est juste un mot que pas grand monde ne connait.

Moi aussi, t'en fais pas

Et je crois quelques autres..

On ne devait pas avoir d'actions chez Borlland

[Theoden]

En gros si je suis bien, pour palier l'incompétence récurente (ou le je m'en foutisme au choix) des boites à faire correctement le bouleau de production / delivery, et pour épargner aux même boites l'effort de se servir de leur cerveau on va pondre une grosse blague d'usine à gaz avec encore ce discours à vomir : "c'est magique on pousse un bouton et ça fait tout tout seul ...."!!!!

Ca me fait penser aux discours récurents que je croise sur les outils de CI où la demande n'est pas d'avoir un outil de contrôle de qualité de code (ce qui est quand même le rôle premier de l'intégration continue) mais d'avoir un gros bouton à clicker pour que le produit sorte packagé (voir carrément installé en prod pour les plus délirants...) ....

Affligeant.

[el_slapper]

En gros si je suis bien, pour palier l'incompétence récurente (ou le je m'en foutisme au choix) des boites à faire correctement le bouleau de production / delivery, et pour épargner aux même boites l'effort de se servir de leur cerveau on va pondre une grosse blague d'usine à gaz avec encore ce discours à vomir : "c'est magique on pousse un bouton et ça fait tout tout seul ...."!!!!

Ca me fait penser aux discours récurents que je croise sur les outils de CI où la demande n'est pas d'avoir un outil de contrôle de qualité de code (ce qui est quand même le rôle premier de l'intégration continue) mais d'avoir un gros bouton à clicker pour que le produit sorte packagé (voir carrément installé en prod pour les plus délirants...) ....

Affligeant.

C'est pourtant l'étape 2 des 12 étapes de Joel Spolsky pour un meilleur code.

Encore une fois, le discours marketo-crypto-foireux autour de l'ALM me débecte, mais il repose sur une vraie problématique : plus on doit faire de choses "à la main", plus on a de chances de se planter.

Je vois ça dans ma mission actuelle. Je fais du cobol. J'ai une seul action à faire pour monter mon composant d'environnement - y compris en prod. Les erreurs de livraison sont rarissimes. Mes collègues qui font du BO/ETL/PL-SQL, eux, passent par des systèmes complexes, qui leur prennent plein de temps. Ils ont beaucoup plus d'erreurs.

Livrer, c'est un mécanisme qui peut comporter beaucoup d'erreurs, et qui, au final, n'apporte pas de valeur ajoutée(contrairement au codage-debuggage, à la spécification, ou à l'homologation). Le réduire à un simple bouton, c'est permettre aux gens de se concentrer sur ce qu'une machine ne peut pas faire.

Après, le contrôle de qualité du code, je n'en ai pas vu qui fonctionne bien - mais comme je bosse généralement sur des monstres spaghettis volants des années 70 ou 80, mon expérience n'est sans doute pas significative.


Si je reviens aux 12 points de Joel Spolsky, je crois que 6 points concernent directement l'ALM :

1.Utilisez-vous un système de gestion de code source ?
2.Pouvez-vous faire un build en une seule étape ?
3.Faites-vous des builds quotidiens ?
4.Avez-vous une base de données de bugs ?
6.Avez-vous un planning à jour ?
7.Avez-vous une spec ?

Et qu'ils n'ont rien de superflu ou d'affligeant. Même si le discours qui les accompagne, souvent, lui.....

[souviron34]

euh.........


N'importe quel outil de gestion de sources style cvs te permet de répondre aux points 1 à 3 avec 2 petits scripts de 10 lignes...

Le point 6 est trivial et est exigé par toutes les méthodologies

Le point 4 est aussi largement connu, que ce soit via juste des documents Wods ou ds outils plus sophistiqués comme les suites Clear...

Quant au point 5, quelles que soient les méthodlogies tilisées, cela dépend principalement des hommes..... Et que ce soit manuel , via MSProject ou n'importe quel diagramme de Gantt, c'est faisable...

[Theoden]

Hum, on va reprendre les choses une à une parce que je pense que le gros bouton est une énorme connerie (comme tous les clicodrômes d'ailleur ...).

C'est pourtant l'étape 2 des 12 étapes de Joel Spolsky pour un meilleur code.

Encore une fois, le discours marketo-crypto-foireux autour de l'ALM me débecte, mais il repose sur une vraie problématique : plus on doit faire de choses "à la main", plus on a de chances de se planter.

Il y a une différence entre avoir X actions à faire à la main, et un gros bouton qui fait tout en cachant la merde sous le tapis. Si un livrable est difficillement déployable, à mes yeux c'est que :

• le livrable est mal conçu
• la procédure de livraison est mal conçue
• le problème est situé entre la chaise et le clavier

Et ce dans cet ordre.

Je vois ça dans ma mission actuelle. Je fais du cobol. J'ai une seul action à faire pour monter mon composant d'environnement - y compris en prod. Les erreurs de livraison sont rarissimes. Mes collègues qui font du BO/ETL/PL-SQL, eux, passent par des systèmes complexes, qui leur prennent plein de temps. Ils ont beaucoup plus d'erreurs.

Les "systèmes" en question ont-ils vocation à exécuter ce qu'on cherche à leur faire éxecuter?

Livrer, c'est un mécanisme qui peut comporter beaucoup d'erreurs, et qui, au final, n'apporte pas de valeur ajoutée(contrairement au codage-debuggage, à la spécification, ou à l'homologation). Le réduire à un simple bouton, c'est permettre aux gens de se concentrer sur ce qu'une machine ne peut pas faire.

C'est vrai et faux en même temps. Livrer sans vraie procédure de livraison réfléchie en amont au cours de la conception / réalisation d'un composant est effectivement source d'erreurs. Dire que ça n'a pas de valeur ajoutée est une hérésie (c'est même une phase qui doit être chiffrée et vendue dans un projet amha et que j'ai chiffré et vendue d'ailleurs et identifiée comme tâche d'admin/livraison/déploiement pas cachée par une coeff sur le chiffrage spec/dev/gp ).

Le coup du gros bouton là où c'est magique c'est quand ça impose de relivrer / repackager l'intégralité des modules d'un produit pour le déployer alors qu'un seul module a bougé et ce n'est qu'un exemple des bourdes que ce genre de blague peut provoquer (livrer pas sur le bon serveur parce que celui ci a changé mais pas le script/ la config derrière le gros bouton et hop adieu l'environnement du client A écrasé par le client B miiip essaye encore ....).

Après, le contrôle de qualité du code, je n'en ai pas vu qui fonctionne bien - mais comme je bosse généralement sur des monstres spaghettis volants des années 70 ou 80, mon expérience n'est sans doute pas significative.

Exemple typique de chose que je n'appelerai pas produit / livrable mais bricollage de bric et de broc qui coûte plus cher à maintenir / évoluer qu'a réaliser au départ. Mais bon au départ l'informaticien c'était géo-trouvetout et ça aller alors... Plus sérieusement le premier step de la qualité du code c'est de faire entrer dans le crâne du développeur que les TU / TI ce n'est pas faire deux fois le boulot et que si ça sert à quelque chose.... Bizarrement une fois qu'on les a forcé à le faire un petit moment (une ou deux itérations de dev par exemple) il ne leur vient pas à l'idée de s'en passer par la suite. Ensuite les chaines d'intégrations utilisées intelligement et surtout suivies par le CTO et bien ça apporte un vrai plus en qualité de livrable/livraison sisi et ça rend même un client heureux à la fin.

Si je reviens aux 12 points de Joel Spolsky, je crois que 6 points concernent directement l'ALM :

Et qu'ils n'ont rien de superflu ou d'affligeant. Même si le discours qui les accompagne, souvent, lui.....

Et bien je ne les connaissai pas et j'avoue que les lire ne m'illumine en rien (ça me parait du basique mais bon passons) et je ne vois pas ce qu'un produit qui fait tout y apporte. Un gestionnaire de source est une évidence dès qu'on bosse en équipe (et bordel m'appelez pas ça sauvegarde ça me hérisse la sauvegarde c'est celle du gestionnaire de source pas celui-ci ... !!!!), faire un build en une seule étape la réponse est forcément oui vu qu'un build (au sens livrable cible ) est forcément basé sur des sous-modules validés et figés (vous ne livrez quand même pas des SNAPSHOTs en RECETTE / PROD si?), le build quotidien c'est le boulot de la CI (au sens validation que ça compile et déploiement du SNAPHSOT sur un serveur de validation interne si il y a lieu), point 3 les outils de traking sont fait pour ça pas besoin de coller ça au cul de la CI / SVN ... le reste relève de la GP pas du delivery n'en déplaise à Borland.

En conclusion je dirai que non le point n°2 sus cité ne correspond pas au gros bouton magique qui fait tout . Ca correspond à un bouleau de gestion de version correctement fait qui veut que tout ce qui ne bouge pas pour une livraison X soit en version figé et disponible sous forme d'artefact à lier à son produit (que ce soit du maven ou autre outil de build des familles (désolé je suis du monde JAVA).

[el_slapper]

(.../...)
Il y a une différence entre avoir X actions à faire à la main, et un gros bouton qui fait tout en cachant la merde sous le tapis. Si un livrable est difficillement déployable, à mes yeux c'est que :

• le livrable est mal conçu
• la procédure de livraison est mal conçue
• le problème est situé entre la chaise et le clavier

Et ce dans cet ordre.

Sauf que nous ne sommes que des humains faillibles. "yaka faire un truc parfait, et nous n'aurons besoin de rien", ça me parait prétentieux et casse-gueule.

Les "systèmes" en question ont-ils vocation à exécuter ce qu'on cherche à leur faire éxecuter?

Je n'en sais rien. Je vois juste que pour remonter un composant, ça passe par 3 équipes et autant de documentation. Donc, autant de possibilités de se louper(et ça ne loupe pas).

C'est vrai et faux en même temps. Livrer sans vraie procédure de livraison réfléchie en amont au cours de la conception / réalisation d'un composant est effectivement source d'erreurs. Dire que ça n'a pas de valeur ajoutée est une hérésie (c'est même une phase qui doit être chiffrée et vendue dans un projet amha et que j'ai chiffré et vendue d'ailleurs et identifiée comme tâche d'admin/livraison/déploiement pas cachée par une coeff sur le chiffrage spec/dev/gp ).

ça ne veut pas dire qu'il faille 5000 steps à se coltiner à chaque fois à la main - avec le risque d'erreur qui va avec.

Le coup du gros bouton là où c'est magique c'est quand ça impose de relivrer / repackager l'intégralité des modules d'un produit pour le déployer alors qu'un seul module a bougé et ce n'est qu'un exemple des bourdes que ce genre de blague peut provoquer (livrer pas sur le bon serveur parce que celui ci a changé mais pas le script/ la config derrière le gros bouton et hop adieu l'environnement du client A écrasé par le client B miiip essaye encore ....).

Ceci a pourtant l'avantage de mettre immédiatement l'accent sur ce qui ne va pas. Si, suite à une modification mineure, je n'arrive pas à repackager le produit, alors j'ai fait une connerie. Paradoxalement, c'est quand il ne marche pas que le gros bouton est utile. Quand il marche, on a l'esprit plus tranquille.

Exemple typique de chose que je n'appelerai pas produit / livrable mais bricollage de bric et de broc qui coûte plus cher à maintenir / évoluer qu'a réaliser au départ. Mais bon au départ l'informaticien c'était géo-trouvetout et ça aller alors... Plus sérieusement le premier step de la qualité du code c'est de faire entrer dans le crâne du développeur que les TU / TI ce n'est pas faire deux fois le boulot et que si ça sert à quelque chose.... Bizarrement une fois qu'on les a forcé à le faire un petit moment (une ou deux itérations de dev par exemple) il ne leur vient pas à l'idée de s'en passer par la suite. Ensuite les chaines d'intégrations utilisées intelligement et surtout suivies par le CTO et bien ça apporte un vrai plus en qualité de livrable/livraison sisi et ça rend même un client heureux à la fin.

Rien à voir. On peut parfaitement avoir des TU, et programmer comme un cochon. Ou avoir un code impeccable, et rien pour le tester. J'ai suffisement vu les deux(et parfois fait, je l'avoue).

Et bien je ne les connaissai pas et j'avoue que les lire ne m'illumine en rien (ça me parait du basique mais bon passons) et je ne vois pas ce qu'un produit qui fait tout y apporte. Un gestionnaire de source est une évidence dès qu'on bosse en équipe (et bordel m'appelez pas ça sauvegarde ça me hérisse la sauvegarde c'est celle du gestionnaire de source pas celui-ci ... !!!!), faire un build en une seule étape la réponse est forcément oui vu qu'un build (au sens livrable cible ) est forcément basé sur des sous-modules validés et figés (vous ne livrez quand même pas des SNAPSHOTs en RECETTE / PROD si?), le build quotidien c'est le boulot de la CI (au sens validation que ça compile et déploiement du SNAPHSOT sur un serveur de validation interne si il y a lieu), point 3 les outils de traking sont fait pour ça pas besoin de coller ça au cul de la CI / SVN ... le reste relève de la GP pas du delivery n'en déplaise à Borland.

C'est du basique? Oui, et c'est assumé. On en est à un point ou la plupart des boites n'en sont même pas là.

De plus, Il y a un point qui correspond aux tests des homologateurs, je suppose que le build correspond à celui qui est envoyé aux homologateurs, pas celui qui est mis à disposition des clients(qui normalement nécéssite un autre clic).

Et c'est là, je crois, que tu fais fausse route : tu pars du principe qu'il suffit que tout le monde soit parfait et aie le temps de tout faire proprement, et que donc des outils qui permettent de gérer la merde sont inutiles.

La merde existe. Elle existera toujours. Tu auras toujours des chefs prétentieux qui diviseront ton estimation par 3, et des programmeurs qui releveront le défi. Moi, je ramasse les morceaux. Et si j'ai des outils pour m'orienter dans ces horreurs, je prends.

En conclusion je dirai que non le point n°2 sus cité ne correspond pas au gros bouton magique qui fait tout . Ca correspond à un bouleau de gestion de version correctement fait qui veut que tout ce qui ne bouge pas pour une livraison X soit en version figé et disponible sous forme d'artefact à lier à son produit (que ce soit du maven ou autre outil de build des familles (désolé je suis du monde JAVA).

"Ce qui ne bouge pas" est un thème hautement imprécis. Il y a souvent des effets de bord. Souvent, souvent, souvent. Non anticipés. Et ils feront planter le bouton rouge. C'est à ça qu'il sert. A renifler le caca même là ou on ne met pas son nez.

[pseudocode]

Encore une fois, le discours marketo-crypto-foireux autour de l'ALM me débecte, mais il repose sur une vraie problématique : plus on doit faire de choses "à la main", plus on a de chances de se planter.

J'ajouterais: et plus on a de chance que ce soit mal fait... voir pas fait du tout.

Bref un problème de compétence, formation, expérience, temps, contraintes, ... Tout ce qu'on rencontre sur des projets fait à l'arrache. Et à bien y regarder, j'ai l'impression que ces outils ALM tout-en-un s'adressent justement à des gens qui ne gèrent pas correctement leurs projets en leur promettant le fameux bouton magique qui va tout gérer à leur place.

De par mon expérience personnelle, je n'ai jamais rencontré un outil qui corrigeait un problème de méthodologie. Au mieux ca cache le problème, au pire ca le met en évidence.

Mon mantra c'est qu'avant d'utiliser un outil d'automatisation, il faut déjà savoir faire correctement le travail sans l'outil.

[Logan Mauzaize]

Je comprends pas trop cet acharnement contre l'ALM ... Ca n'a rien de neuf en soit mais c'est tout intégré et c'est déjà pas rien.

Vous préférez gérer dix milles feuilles Excel (souvent à moitié buggée) et jamais à jour ? Moi, je préfère un tableau de bord toujours en adéquation entre les bugs, les tâches, les exigences, les tests, etc.