Quelle approche pour la conception des SI ?
Quelle approche pour la conception des SI ?
« La synthèse des meilleures approches par la modélisation : SOA, UML2, BPMN,… »
Le 23/09/2008, par MEGA International, pour le lancement de MEGA System Blueprint
Durée : ½ journée
Objet : Lancement du nouveau module MEGA System BluePrint (anciennement IT Designer) par MEGA International.
Sujet 1 : Spécification des SI, une nouvelle stratégie par [1]
Plutôt que de faire un rapport précis sur l’outil je vais livrer plutôt des points méthodologiques et des définitions évoquées. Cette restitution sera chronologique vis-à-vis de la présentation donnée et de l’ordre des intervenants à savoir : François Tabourot (Directeur Général) [1] ; Antoine Lonjon (Directeur Méthodes) [2] ; Patrick Bessodes (Business Consulting manager) [3] et Olivier Le Guellec (Responsable Avant-Vente) [4].
Un petit retour sur l’histoire de MEGA et initialement de la société GAMMA qui avec le lancement de MERISE à donné MERISE + GAMMA = MEGA. Constat aujourd’hui il y a toujours eu un budget plus important pour le développement et beaucoup moins important pour les spécifications. « Les ERP vont nous formaliser, et nous allons nous adapter à eux » [1] et de plus il y a eu transfert du problème vers les sous-traitants intégrateurs, les out-sourceurs. Mais tout cela a été plus complexe que prévu, les ERP n’ont pas résolus les problèmes (bien au contraire), les intégrateurs ont montrés leurs difficultés à respecter des engagements et d’un autre coté il ne faut pas non plus s’enfermer dans les spécifications sinon cela devient vite lourd : il faut trouver un juste milieu pour l’expression des besoins. MEGA 2009 et son nouveau module MEGA System Blueprint est là pour combler ces lacunes à base des normes et standards : BPMN, SOA, UML2.0. Un nouveau concept est introduit : avoir un référentiel de spécifications, normé, organisé et formalisé afin de pouvoir réutiliser et avancer plus vite au sein des projets : « Un référentiel de spécifications est une notion unique au monde ; aucun autre éditeur ne le fait, du moins pas à notre connaissance » [1].
Sujet 2 : Analyse et conception des systèmes applicatifs
La modélisation au service des nouvelles approches de conception par [2]
Retour brefs sur les premières approches et méthodes : industrialisation de l’informatique avec la standardisation des fonctions (ERP), la programmation orientée objet (POO) avec les bibliothèques de composants (composant sur étagère). Deux objectifs sont mis en avant à ce moment là : appliquer les méthodes de l’industrie à l’informatique et diminuer les coûts en utilisant des composants prêts à l’emploi. Donc nous pouvons retrouver deux approches : soit par les processus (intégration de progiciel ; réutilisation des fonctions d’ERP) ou soit par l’orientation objet (composants réutilisables). La conception est donc délaissée car les méthodes de conception ne plaisent pas : « Les départements d’E&D ont envie d’UML mais en même temps ils en ont peur » [2]. Aujourd’hui les entreprises expriment un besoin croissant en terme d’autonomie d’intégration et la volonté d’une approche SOA avec le développement de service (au sens service applicatif). Or les SI sont devenus très hétérogènes avec des méthodes, des conceptions différentes au sein même de chaque entreprises. Aujourd’hui les critères pour un cadre de conception opérationnel sont d’avoir une communication globale avec tous les acteurs du projet, fonder les techniques de modélisation sur l’adoption des standards internationaux notamment BPMN pour les processus, SOA et UML2.0. Et le constant sans appel pour Merise qui ne peut suivre la diversité actuelle…Les nouveaux standards de modélisation permettent d’aborder la complexité de manière simple et cohérente ce qui permet de ne pas mélanger les problèmes. (NB. = il y a une prise en compte de la complexité des SI ? ) Présentation du cycle en V de conception habituel couplé à une matrice basée sur le modèle de Zachman ([5]) La solution MEGA se veut être le bon modèle, pour les bonnes personnes, au bon moment.
Questions posées par l’assistance :
Q1 : Comment passer d’une méthode itérative au cycle en V et inversement ?
R : Le cycle en V permet d’avoir une histoire : un début et une fin, de plus l’ingénierie est plus que nécessaire dans le cadre d’audits, de justification, …
Q2 : Il y a une confusion entre SI et application dans l’exposé…
R : IT planning c’est pour la planification du SI au sens global tandis que System Blueprint est pour la conception d’application avec notamment le cycle en V. MEGA se veut pivot entre SI, EA et applications.
Q3 : Est-il possible d’avoir une traçabilité des itérations dans le cycle en V ?
R : Projet prioritaire à MEGA
Sujet 3 : Analyse et conception des systèmes applicatifs
La modélisation au service des nouvelles approches de conception par [3]
Retours sur les méthodes utilisées jusqu'à maintenant :
MERISE à vision à trop long terme, trop rigide, … abandonnée
RAD [6] à absence de CDC complet, pas de vision globale, pas de validations intermédiaires
ERP à les vrais besoins du clients sont oubliés, pas de prise en compte du contexte complet
UML à utilisé en pensant résoudre les problèmes méthodologiques, échec de l’universalité, la MOA ne pouvait/ne peux pas valider les spécifications UML ;
Exemple d’une grande société française avec un lourd projet à développer constitué comme suit :
Chaque sous-traitant se voit confier une partie du projet et la seule consigne méthodologique donnée aux sous-traitants est : utilisez UML pour les spécifications. A la fin de chaque développements effectués le projet est assemblé, mais aucune des sous parties ne pouvait communiquer entre elles, pas de référentiels communs, pas de dictionnaires sémantique communs donc le projet est passé au statut HS….
Les outils utilisés pour écrire les spécifications aujourd’hui sont des outils de bureautique (Word, Excel, PowerPoint,…) du coup pas de formalisation des spécifications pour quelle qualité ? Quelle pérennité ? Et quelle maniabilité ? Plusieurs Go de documents Word peuvent être produits pour un et un seul projet : document inexploitables, indigestes, impossibles à analyser et qui forment des spécialistes (souvent irremplaçables) sur chaque sujet puisque seul celui qui a rédigé les documents a une vision réelle (et globale ?) du projet. De plus bien souvent pas de dictionnaire de données (de simples problèmes de longueur de champs de données peuvent poser d’énormes problèmes sur la communication entre applications).
Il n’y a donc pas de réutilisation des spécifications, redondance des tâches, il n’y a pas de partage mais bien souvent des relectures de document : « Au plat de spaghettis habituel des interfaces applicatives, on ajoute un plat de spaghettis documentaire… » [3]
Une autre problématique actuelle est l’externalisation de la MOE (surtout à l’étranger, en Inde par exemple) la formalisation des spécifications n’est pas asser poussée : l’interprétation des développeurs peut dépasser l’imagination la plus folle face au manque de formalisme des spécifications.
Afin de palier à tout cela il doit y avoir un référentiel projets qui s’appuie sur le référentiel d’urbanisation, sur la cartographie afin de se réapproprier et maîtriser la connaissance du SI et justifier les décisions prisent vis-à-vis du SI. Il faut revenir sur les bonnes pratiques qui ont été abandonnées petit à petit : utiliser les cas d’utilisation, consacrer du temps pour rédiger les spécifications et pour cela MEGA a la solution : MEGA System blueprint.
Sujet 4 : MEGA System Blueprint
Démonstration par [4]
L’idée est donc de se baser sur le cycle de développement en V, qui n’est qu’un guide et n’est pas obligatoire dans MEGA. A partir du CDC fonctionnel on définit les processus métier cibles (processusàprocéduresàtaches avec la notation BPMN [8] puisque MEGA 2009 supporte la version 1.1) Pour passer ensuite à l’analyse fonctionnelle en partant des cas d’utilisation du système (qui permet de faire le lien entre architecture métier et architecture applicative) et faire correspondre à chaque cas d’utilisation un processus applicatif qui est décomposé lui-même en tâches informatiques (qui sont remplies soit par d’autres processus applicatif, soit par des composants applicatifs / des services applicatifs) à la façon BPMN. MEGA System Blueprint utilise donc la notation BPMN (appliquée aux processus) pour décrire l’application fonctionnellement avec les notions de processus applicatifs afin de pouvoir, par la suite, décrire l’architecture applicative avec l’architecture des services et l’architecture applicative de manière générale.
L’exemple présenté parlait donc d’un système de SAV (Service Après Vente) : l’une des procédures du processus était « Enregistrer réclamation client » qui était décomposée à son tour. Dans cette décomposition on pouvait retrouver le composant applicatif : « Rechercher un client par son nom » qui était découpé en tâches regroupées suivant trois visions/séparations/perspectives/participants à savoir une notion d’interface, de logique métier et d’accès aux données selon le pattern MVC ([9] Model View controler). Chacun de ces participants (nouveau concept dans MEGA 2009) peux ainsi être soit un autre composant applicatif, soit une autre application, soit un acteur. Chacune des tâches du participant interface peuvent aussi recevoir une interface graphique, dessinée directement dans MEGA, ou depuis Paint (Windows) ou encore depuis Photoshop.
Questions posées par l’assistance :
Q1 : Est-ce qu’une méta classe Test va voir le jour dans MEGA ?
R : pas dans MEGA ; liaisons avec des outils de tests du marché comme test director [11] par exemple ; mais pas de standards en la matière donc plusieurs sont possibles mais pas tous.
Q2 : Blueprint est un système de communication formel entre les différents acteurs du projet mais pas de présence MEGA en Inde : comment faire utiliser MEGA par nos sous-traitants indiens ?
R : contacts en cours…
Résumé sur les grandes questions par Jacques Printz :
Problèmes de modélisation : jusqu’ou modéliser ? Avoir des Go de documents word ce n’est pas souhaitable, mais avoir des Go de modèles n’est pas non plus forcément pratique. Il faut assurer la communication entre la MOA et la MOE de manière fiable, c’est pour cela qu’il faut des architectes compétents ; c’est absolument vital ; l’outil est une chose mais sans un bon architecte l’outil n’est rien : il faut produire le bon modèle !
Il faut se comprendre et pour cela il faut s’appuyer sur :
les standards internationaux
la sémantique
la syntaxe
la présentation (agréable à l’œil)
Il faut cependant modéliser, cela reste le moyen le plus sur aujourd’hui mais il faut absolument s’entourer d’une gestion de configuration ([10] stocker et tracer les différentes versions ou révisions) et d’un bon système de test : vital quand à la réussite des projets.
Références :
[5] John Zachman, IBM
http://www.12manage.com/methods_zachman_enterprise_architecture_fr.html
http://fr.wikipedia.org/wiki/Cadre_Zachman
http://www.journaldunet.com/solutions/acteurs/classement/08/bpms/0404-zachman.shtml
[6] RAD pour Rapid Application Development : méthode de développement logiciel
http://fr.wikipedia.org/wiki/D%C3%A9veloppement_rapide_d%27applications
[7] Blueprint: A blueprint is a type of paper-based reproduction usually of a technical drawing, documenting an architecture or an engineering design. More generally, the term "blueprint" has come to be used to refer to any detailed plan.
http://en.wikipedia.org/wiki/Blueprint
[8] BPMN maintenue par l’OMG (Object Management Group)
http://fr.wikipedia.org/wiki/Business_Process_Modeling_Notation
http://www.journaldunet.com/solutions/acteurs/classement/08/bpms/0207-norme-bpmn.shtml
http://www.omg.org/docs/formal/08-01-17.pdf : Spécifications BPMN 1.1 (janvier 2008)
[9] MVC
http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur
http://julien-pauli.developpez.com/tutoriels/php/mvc-controleur/
[10] Gestion de configuration
http://fr.wikipedia.org/wiki/Gestion_de_configuration
http://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle
[11] Test Director
http://en.wikipedia.org/wiki/Mercury_Interactive