urbanisation-si

urbanisation-si

Pour commencer : tout ce qu'il ne faut pas faire


Ne soyez pas raciste avec la technique !

urbanisation-si-GWT.gif

Lors de différentes missions, j'ai pu constater un certaine répugnance à tout ce qui touchait de près ou de loin à la technique. Coté MOA, AMOA, analystes métiers, …, les informaticiens étaient appelés péjorativement des "tékausse". On reprochait même à certains analystes d'être trop techniques dans leurs spécifications. Ce dédain pour les aspects réalisation technique pouvaient même aller jusqu'à passer à coté du dossier d'architecture technique. Les développements étaient sous-traités à une grande SSII qui devaient s'occuper de tout. C'est comme confier la décoration de son appartement à un architecte d'intérieur en lui disant "allez-y" sans autre directives et contrôles. Les mauvaises surprises arrivèrent bien vite. Quand la MOE chiffra les écrans, on arriva vite à des points de désaccord. Un écran utilisant 3 entités métiers, 4 zones de saisie, une liste déroulante, 3 boutons (Annuler, Enregistrer, Supprimer) étaient qualifié de complexe avec une charge de 12 jours de charges !  

Que s'était il donc passé ? 

Les parties prenantes par inexpérience de grands projets informatiques avaient négligé de s'allier les compétences d'experts en architecture et gestion de projet informatique pour les conseiller sur la réponse faite à l'appel d'offre. Les métriques d'estimation proposées par la SSII ne furent pas analysées et discutées. La direction de projet signa un chèque en blanc encore une fois par méconnaissance des méthodes et outils modernes d'amélioration de la productivité et du retour sur investissement. Les référentiels de bonnes pratiques comme CMMI, ITIL, eSCM étaient écartés car ce n'était pas le genre de la maison, "nous on est métier , MOA", on ne mélange pas les serviettes et les torchons ! 

Donc cette organisation se retrouva avec un chiffrage d'écran exorbitant, sortant largement des standards du marché. 

Quelles en étaient les causes ? 

Quand ne connaît pas un sujet, qu'on ne le maîtrise pas ou qu'on ne le comprend pas on s'attache les services d'un consultant expert avec une des retours d'expérience réussis dans le domaine considéré. Le projet avait des contraintes techniques, un existant imposé à faire évoluer. Le fait de s'appuyer sur une application existante utilisant des frameworks obsolètes, utilisant des vieux programmes mainframe, entraîna de fortes contraintes  techniques comme le fait par exemple de ne pas pouvoir utiliser les derniers outils pour le RIA (Rich Internet Application comme : Angular JS, Ext JS, GWT, PrimeFacesRichFacesWicket, …) pour des raisons d'incompatibilité totale. 

Tous les composants graphiques de base furent entièrement développés manuellement avec les technologies d'il y a 15 ans (TagLib ,JSTL, JavaScript). Tous les comportements évènementiels IHM étaient écrits manuellement en JavaScript alors que plus personne ne fait ça aujourd'hui, ce serait comme développer une application de gestion en assembleur ! Quand on demanda le dossier d'architecture du projet, on nous dit qu'il était en cours de rédaction alors que la première bonne pratique est de valider l'architecture en tout début de projet et de ne pas se lancer dans la production de code sans cette validation. La méthode UP (Unified Process) spécifie même une phase propre à cette validation, la phase d'élaboration. 

N'ayant pas de contre expertise, la SSII en profita donc pour imposer ce qui l'arrangeait le mieux.  

Le projet ayant pris beaucoup de retard par ailleurs et les développements ayant commencé, il ne restait plus à l'organisation le choix cornélien, soit de payer ou soit d'arrêter le projet ! 

 

 

"Il faut tenir une résolution parce qu'elle est bonne et non parce qu'on la prise"

 

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/


15/10/2014
0 Poster un commentaire

1/11 Projet informatique : passer du moyen âge à l'ère industrielle. Tout ce qu'il ne faut pas faire !

projet-informatique.jpeg

 

Les projets informatiques nécessitent une méthode spécifique intégrant un ensemble de bonnes pratiques que l'on peut à loisir enrichir et adapter. Sans la mise en place d'une telle méthode, on s'expose à un gaspillage important de ressources voire faire couler le projet.

 

Cette série d'articles à pour but de montrer l'intérêt d'avoir une vision globale pour le développement d'application informatique et l'importance d'une méthode intégrant un maximum d'outils et de bonnes pratiques aussi bien pour la MOA que pour la MOE afin d'améliorer le retour sur investissement (ROI) et de ne pas rester au moyen âge mais de rentrer enfin dans l'ère industrielle.

Et si le développement informatique sortait du travail artisanal ?

Imaginer la construction artisanal d'une voiture ou chaque pièce serait usinée à la main ! Une fois la voiture terminée on l'essaye pour s'apercevoir que le moteur ne fonctionne pas !

Toutes les grandes industries comme l'aviation, l'automobile, la téléphonie mobile, etc, ont leurs processus de production bien rodés depuis la conception, les bancs de tests de composants automatisés jusqu'à l'assemblage robotisé.

Peut on encore en 2014 construire des composants logiciels comme un horloger du moyen âge forgeant et ajustant chaque engrenage d'une horloge ?

Assurément non, et pourtant aujourd'hui encore les applications informatiques stratégiques dans le monde bancaire, assurantiel ou autre sont réalisées de manière artisanales sans processus industriels.

Examinons un cas à peine caricatural rassemblant diverses situations auxquelles j'ai été confrontées. Considérons une application de liquidation de dossiers de sinistres dans le cadre d'un projet de modernisation du SI d'une compagnie d'assurance.

Le démarrage du projet se fait sans la mise en œuvre d'une méthode technique spécifique à un projet informatique genre UP (Unified Process), XP (eXtreme Programming), Scrum, .... Chaque étape se succède séquentiellement de manière qu'on pourrait qualifier de méthode "rigide". J'ai même vu des société communiquant sur la méthode "agile" pour avoir l'air moderne alors qu'elles ne comprenaient pas de quoi il s'agissait réellement.

La chaîne complète de fabrication est ignorée. Il n'y a pas de vision globale de projet informatique intégrant l'agilité , l'urbanisation, l'architecture technique, la gestion des processus et des règles métier, ...

Le travail des analystes consiste à concevoir des écrans sans se soucier des processus métier transverses.

Quels rôles métier vont jouer les utilisateurs ?

Quels sont les cas d'utilisation de la future application, de quels scénarios sont ils composés, qu'elles sont les alternatives, les exceptions métier ? Les cas de tests ne sont pas fait tout de suite, on verra plus tard !

On dessine des écrans très complexes avec PowerPoint voire des outils spécialisés sans se préoccuper de la faisabilité et du coût technique de réalisation.

Quand aux traitements prévus sur l'action des boutons, aucune méthode d'organisation en services, d'ailleurs le terme est à peine connu.

Les spécifications fonctionnelles générales (SFG), détaillées (SFD) et technique (STD) sont faites à partir de modèles n'intégrant pas les techniques objet pour l'évolutivité, la réutilisabilité et la maintenabilité.

Le formalisme normalisé et universellement utilisé UML (Universal Modeling Language) est complètement ignoré.

Le modèle de données utilise un mélange Merise de MCD (Modèle Conceptuel de Données) et de MPD (Modèle Physique de Données) sans guide méthodologique.

Les concepts de processus métier, d'événement déclencheur, de tâches, d'objectifs, d'objets manipulés en entrée/sortie, de modélisation de processus, de processus métier exécutables, de réorchestration de processus, ... sont complètement inconnus ou sont volontairement écartés par peur de ce que l'on ne connaît pas ou pour ne pas avoir d'effort à fournir pour en acquérir la maîtrise.

Le métier ne comprend pas les analystes qui ne comprennent pas les développeurs qui ne comprennent pas le métier.

Aucune vision globale, aucune ambition d'automatiser, de gérer l'évolutivité, la maintenabilité, la réutilisabilté, la traçabilité, la génération de code et de documentation.

L'implémentation des spécifications est souvent sous-traité à une SSII sans méthode de communication MOA-MOE et c'est la que les problèmes de compréhension surviennent et le début d'éventuels contentieux.

La MOA n'a pris aucun expert pour analyser les réponses aux appels d'offres, si bien qu'elle s'expose à des pièges dans les métriques servant aux estimations de charges. Par exemple le soumissionnaire peut omettre le facteur de réutilisation qui bien géré peut faire baisser de manière non négligeable les charges.

Mais comme aucune méthode avec les retours d'expérience et les adaptations nécessaires n'ont été appliqués, tout part de travers !

Et pourtant les concepts, les méthodes, les outils, les bancs de tests, les méthodes d'estimation pour ne pas se faire avoir par les SSII qui vont réaliser les développements, tout cela existe et est largement utilisé par les industriels.

C'est ce que nous verrons au prochain épisode.


Voir aussi le site :

Abandonnez le classicisme, relookez votre SI


15/08/2014
2 Poster un commentaire

Recherche

Vous recherchez ? :