MENU
THEMES

ALM : Application Lifecycle Management

Publié le: 18/09/2007  |  Par: Guideinformatique  

Développer une application qui réponde aux besoins des utilisateurs dans les limites de temps et de ressources prévus, la déployer et la maintenir correctement, autant d'objectifs qui sont sous la surveillance de l'ALM (Application Lifecycle Management).
Bref, un outil de pilotage des développements.

Principe de l'ALM

Entre les besoins des métiers et la production informatique on trouve des équipes de développement qui disposent de moins en moins de temps pour développer.
Ces équipes doivent répondre à 2 impératifs principaux :

  • répondre précisément à l'expression des besoins métiers,
  • rester dans des limites de ressources et de délais impartis.

De même qu'il existe des applications pour optimiser la production de l'entreprise, il existe également des applications pour optimiser les développements : c'est l'ALM (Application Lifecycle Management ou Gestion du Cycle de vie des Applications).
En premier lieu, sont apparues les applications de gestion de planning et de ressources, comme MS Project. L'ALM étend ces fonctionalités :

  • en amont, elle aide à la définition des besoins,
  • en aval, elle encadre les déploiements ainsi que les différentes phases de maintenance et d'amélioration.

Ainsi, c'est tout le cycle de vie de l'application qui est couvert, de l'expression de la première idée, jusqu'à son abandon définitif.

Le cycle de vie d'une application

Au départ, il y a une idée ou un besoin, pour qu'elle se transforme en service métier 4 grandes étapes seront suivies :

  • l'établissement du cahier des charges,
  • le développement proprement dit,
  • les phases de test et de documentation,
  • la mise en production et la maintenance.

Après la mise en production, des demandes de correction ou d'amélioration verront probablement le jour et le cycle recommencera jusqu'à la mort de l'application.

Définition et gestion des exigences

On le sait maintenant, un projet connaît des difficultés, moins par manque de technique ou d'organisation, que par une mauvaise définition ou une mauvaise compréhension des exigences des utilisateurs. L'ALM portera donc une grande attention à cette phase de définition ainsi qu'au contrôle permanent des réalisations avec cette définition.
L'ALM propose donc 3 types d'actions :

  • collationner toutes les exigences (directement ou sous format Word, Excel, Access...) et les mettre dans une base de données,
  • classer et nettoyer les exigences,
  • organiser un niveau de décision.

L'ensemble du cahier des charges est alors terminé.

Un système de workflow surveille l'arrivée des infos et leur validation. L'émetteur doit pouvoir suivre l'évolution de ses exigences et leur impact

Développement, production

Le développement permettra de produire des composants métiers adaptés aux exigences.

L'ALM acceptera les différentes méthodes de modélisation utilisée dans l'entreprise (comme UML) et assurera l'interopérabilité avec les différents IDE comme Visual Studio.NET, Macromedia Studio, Delphi, JBuilder et Eclipse ou NetBeans...
A noter l'initiative ALF d'Eclipse, dont le but est de permettre aux briques de communiquer et qui rassemble déjà une trentaine d'éditeurs.
Enfin, l'ALM doit répondre pour son domaine, aux exigences des référentiels de bonne pratique comme CMMI.

Mise en exploitation, déploiement

Une application métier rassemble de nombreux composants, faisant appel eux-mêmes à de nombreux modules. Chacun ayant probablement connu plusieurs versions.
Mettre en ligne une application pour une version donnée, consiste donc à assembler tous ces modules des dernières versions compatibles entre elles et, ce, pour chaque environnement. Pas simple. D'autant que la prochaine version de l'application sera, elle aussi, un savant cocktail de nouvelles versions (ou pas) de ces modules. Pour compliquer le tout, un utilisateur ou un client peut travailler sous une version et un autre sous une autre plus récente.
Le système doit donc permettre de suivre les évolutions de version et de savoir regénérer une ancienne version. On parle de gestion des changements et de gestion des versions.
Enfin, la phase de déploiement doit prendre la bonne version (Linux, Java, mainframe) et l'envoyer vers le bon serveur.

Maintenance, service support

Dernière étape du cycle et première du prochain, cette phase permet de collecter les incidents et, si nécessaire, définir de nouvelles exigences.

ALM 2.0, PPM et Process Management

On parle parfois d'ALM 2.0 pour désigner les dernières évolutions de l'ALM qui combinent ALM, PPM et Process Management.
Le PPM (Project Portfolio Management) permet de gérer des ensembles de projets :

  • les ressources (compétences Java, Oracle .Net - le plus souvent délocalisées)
  • les délais et priorités (il y a généralement plus de projets que de ressources et il faut aligner les priorités)
  • les budgets, bien sûr,
  • les priorités du business (comment répondre au mieux aux impératifs métiers).

Le Process Management permet de gérer les processus de production de versions d'applications au même titre que les autres processus de production d'une entreprise.
Il possède un moteur d'orchestration et peut modéliser, personnaliser, agencer et déployer des processus de production et déploiement dans des environnements hétérogènes.
Enfin, il ne faut pas oublier le référentiel qui désigne tous les composants informatiques (lignes de code, doc, exécutables...) et permet la traçabilité nécessaire (notamment pour les domaines de la pharmacie, l'agriculture, la banque ou les telco).
 
Merci à Frédéric Richer, Directeur Marketing France de Serena Software, pour son aide dans l'élaboration de cette fiche.

Dossiers dans la même thématique ...

Réagir à cet article