urbanisation-si.com

urbanisation-si.com

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

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 705 autres membres