L'ALM trop mal connu mais de plus en plus utilisé, d'après Borland
Qui sort un baromètre sur la gestion du cycle de vie des applications
Le 2013-01-16 10:45:16, par Gordon Fowler, Expert éminent sénior
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.
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 ?
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.
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 ?
-
souviron34Expert éminent séniorJe 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...le 17/01/2013 à 15:26 -
tetanosMembre à l'essaiFranchement, 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?le 17/01/2013 à 16:28 -
souviron34Expert éminent séniorTout à fait..
Moi aussi, t'en fais pas
Et je crois quelques autres..
On ne devait pas avoir d'actions chez Borllandle 17/01/2013 à 17:00 -
Logan MauzaizeRédacteur/ModérateurJe 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.le 11/02/2013 à 20:44 -
el_slapperExpert éminent séniorJ'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.le 17/01/2013 à 16:52 -
TheodenMembre du ClubEn 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.le 18/01/2013 à 9:42 -
el_slapperExpert éminent séniorC'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 ?le 18/01/2013 à 10:24 -
souviron34Expert éminent sénioreuh.........
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...le 18/01/2013 à 10:58 -
TheodenMembre du ClubHum, 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 ...).
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.
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.
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.
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.....
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). le 18/01/2013 à 15:49 -
el_slapperExpert éminent séniorSauf 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.
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).
ça ne veut pas dire qu'il faille 5000 steps à se coltiner à chaque fois à la main - avec le risque d'erreur qui va avec.
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.
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).
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.
"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.le 21/01/2013 à 10:33