Archives de Catégorie: Développement Agile

Il est temps de s’occuper de l’existant…

Les entreprises ont ajouté des vagues de nouvelles technologies, démarrant souvent des nouveaux projets avant même d’avoir achevé les précédents, le tout avec des résultats décevants mais la frénésie était telle qu’on remettait à plus tard bilans et examens. Cette période a atteint son point culminant à la fin de l’année dernière avec la notion de « temps Internet » qui justifiait de développer « vite fait-mal fait » des projets sans objectif, sans stratégie et sans résultat mesurable. Maintenant que cette effervescence est retombée, le bilan est lourd.

Les deux dernières années ont été terribles pour le monde de l’informatique habitué à des taux de croissances confortables : les clients ont réduit leurs dépenses destinées aux nouveaux systèmes de 15 à 20% en moyenne alors qu’ils avaient investi massivement lors de la dernière décennie (avec des augmentations annuelles des dépenses d’investissement de l’ordre de 5 à 10%).

Ce contexte morose n’est pas vraiment surprenant : non seulement l’éclatement de la bulle Internet a « coupé les jambes » des projets de sites Web et d’Internetisation mais les déceptions ont également été nombreuses dans des domaines en vogue comme le CRM ou les ERP.

Tout cela combiné a provoqué une crise de confiance qui s’est traduite par un coup d’arrêt radical dans les dépenses. Comme si tous les directeurs informatique s’étaient passés le mot en même temps : j’arrête d’acheter !

Tous les responsables informatique, interlocuteurs des acteurs du marché répètent maintenant le même cri du coeur : ne me vendez pas de nouveaux systèmes, aidez-moi plutôt à faire marcher ceux que vous m’avez déjà vendus… C’est un retournement de marché qui est radical et sans doute durable. Car, même en baisse, les dépenses informatiques sont tout de même là, pas pour des nouveaux projets mais seulement pour entretenir l’existant et il y en a !

Depuis la fin de la bulle Internet, les opérations d’EAI sont devenues une priorité évidente pour la plupart des entreprises afin de retrouver un minimum de cohérence. C’est ainsi que nous sommes entrés pour au moins deux ans dans une période caractérisée par la volonté de consolider, d’intégrer et d’optimiser l’existant.

Même les éditeurs d’applications s’y sont mis comme SAP qui, dernièrement, a choisi les Web Services afin d’offrir un accès à ces processus sans avoir à choisir entre J2EE et dotNet… En conséquence, les Web Services ont été mis en avant comme l’alternative légère et idéale pour les opérations d’EAI…

Le fait que les Web Services se soient retrouvés mis en vedette dans le cadre de l’EAI n’est pas surprenant : les Web Services basés sur le protocole SOAP se révèlent être une technique peu intrusive et donc relativement facile à mettre en place, surtout si l’on compare aux autres solutions de middleware qui ont précédé les Web services comme DCOM ou CORBA (après tout, il ne s’agit que d’une RPC légère reposant sur XML) …

On assiste en ce moment à l’apparition d’une nouvelle offre de solutions mixant les avantages des Web Services, des connecteurs (comme JCA), des middlewares messages (comme JMS) et combinant le tout dans une infrastructure d’intégration et de gestion appelée ESB pour Enterprise Services Bus. 

Publicités

D’une mentalité de Nomades à une mentalité de bâtisseurs…..

Certaines entreprises disposent de systèmes d’information formés d’un empilement « au fil de l’eau » des applications. Elles se sont construites au fur et à mesure, les interfaces, non normalisées, se sont développées spécifiquement et propagent au lieu de les absorber, les contraintes d’évolution, rigidifient et fragilisent le SI. Il n’y a pas d’infrastructure cohérente. Ce type de SI est présent surtout dans les banques.

La problématique qui se pose alors est la suivante : « comment continuer à faire évoluer le système » ?

Par contre d’autres entreprises ont un SI présentant des applications développées sans souci de communication. Ce type de SI est un modèle que l’on pouvait voir dans les grands systèmes hospitaliers par exemple (un malade peut être connu du service administratif mais pas du service qui va le soigner). Faire évoluer le système est là aussi compliqué : des données sont répliquées, il faut de plus faire communiquer les systèmes entre eux.

On pouvait aussi rencontrer certains SI ou les applications communiquent. Ceci dit, le SI n’est ni homogène (il n’y a pas d’infrastructure fédératrice, les différents systèmes composants sont restés tels quels, développés avec des outils différents par exemple), ni structuré (la réflexion n’est pas menée d’après les composants du système d’information dans une étude d’architecture globale).

Pour résumer, les DSI sont dans la situation suivante : il n’est plus possible de faire évoluer le système sans le reconstruire et refondre le système dans le contexte que nous venons d’évoquer devient impossible pour des raisons de :

  • complexité : « la complexité fait qu’on a du mal à en contrôler l’avancement, et à réunir les équipes compétentes nécessaires, ce qui oblige à faire largement appel à la sous-traitance et rend plus problématique encore la maîtrise globale. »
  • délais
  • coûts

Il faut savoir que la valeur ajoutée d’une refonte totale de système est marginale. On estime à seulement 20% la part du système totalement repensé, le reste (80%) étant refait à l’identique. Par contre le risque pris lors d’une telle transformation et le coût portent sur les 100% du projet. Rappelons que les directions informatiques sont alors liées à leurs constructeurs et veulent sortir de ces monopoles, reprendre les rênes de leurs solutions informatiques.

Aujourd’hui, les enjeux pour les DSI sont alors les suivants :

  • Comment continuer de faire évoluer le système dans la maîtrise des coûts et de délais ?
  • Comment le faire en concentrant l’effort sur les parties à plus forte valeur ajoutée ?
  • Comment, dans le même temps se libérer du joug des gros constructeurs ?

Ne faudrait-il pas que les informaticiens « passent d’une mentalité de Nomades à une mentalité de bâtisseurs ? »

L’industrialisation est avant tout une culture

L’industrialisation du développement consiste à déployer des pratiques et outils visant à rendre les logiciels développés plus robustes, tout en restant dans des délais et coûts maîtrisés. Cette montée en maturité repose généralement sur une plateforme de développement de type industriel. Cette plateforme est schématiquement basée sur deux outils serveurs :

  • Une chaîne de gestion de projet permettant : partage des documents projets, suivi d’avancement des équipes, reporting des anomalies/bugs, synthèse de l’avancement projet sous forme de tableau de bord. Cette première chaîne permet la maîtrise des délais et coûts du développement;
  • Une chaîne d’intégration continue permettant : tests automatiques, assemblage de l’application, génération de documentation, déploiement. Cette seconde chaîne permet la maîtrise de la fiabilité et de la robustesse des logiciel
La complexité croissante des projets applicatifs actuels implique la mise en place d’usines de développement. Ces « usines » permettent de limiter les tâches répétitives pour les développeurs en leur fournissant un système complet d’intégration automatique des différents éléments d’un projet.

Plus concrètement, certains projets possèdent des dizaines de développeurs et la taille de l’application implique parfois des heures de compilation. De plus, si des tests unitaires sont couplés à ce processus, la mise en place d’un serveur d’intégration continue s’avère essentielle pour la qualité d’exécution d’un tel projet.

Voici un exemple de principe d’intégration continue qui reprend certains aspects énoncés par les méthodes dites « agiles » :
1 – L’équipe de développement programme la journée sur un projet en utilisant un outil de contrôle de version (SVN).
2 – Un développement est terminé pendant la journée, le développeur concerné le met à jour dans le contrôle de version (checkin).
3 – Le système d’intégration continue détecte la mise à jour des sources et lance une compilation incrémentale (qui n’implique que le bloc de code mis à jour).
4 – La journée se termine.
5 – La nuit, à heure fixe, une compilation complète du code est démarrée grâce au système d’intégration continue. On appelle aussi ce processus le nightlybuild.
6 – La compilation se termine, une série de tests unitaires sont lancés pour valider la nouvelle version compilée.
7 – Le matin, le chef de projet et les développeurs ont accès à un reporting convivial sur les résultats du nightlybuild.

Le principe d’intégration continue est intéressant pour de nombreux projets naissant ou existant depuis longtemps. Il permet, en plus d’automatiser, de valider la qualité d’une application et d’informer, non seulement les développeurs, mais aussi le client ou la maîtrise d’ouvrage du projet.

Les consultants du cabinet OPENI sont à votre disposition pour vous accompagner à la mise en place d’usine de développement et la définition du socle de développement et du Framework à base de la technologie Java ou .NET.

Tagué