Le projet PY
Présentation[modifier | modifier le wikicode]
Ceci n'est pas un jeu, c'est un serious game !
Vous allez découvrir le projet ΠΥ.
Voici en quelques mots de quoi il s'agit.
Je mets en place une plate-forme d'échange d'expertise sur la modélisation des SI et le développement logiciel. Elle se compose pour l'instant d'un Wiki et d'un modèle sous Entreprise Architect, son accès est restreint à des personnes que je coopte.
Il s'agit plus prosaïquement de prolonger le travail commencé chez CS pour les développements du produit de back office et de hub avec l'équipe américaine.
Pratique de la modélisation[modifier | modifier le wikicode]
Ce chapitre justifie la pratique de la modélisation et pose les trois concepts de base : langage - méthode - outil.
ΠΥ[modifier | modifier le wikicode]
ΠΥ est l'association de la lettre Π (pi) qui symbolise le pentagon du pentagon model qui est à la base de la conception des système de gestion commerciale interopérable et de la lettre Υ qui symbolise le cycle de vie dit en Y.
Le projet ΠΥ consiste à rassembler sur une plate-forme unique, centrale et ouverte toutes les informations nécessaires pour concevoir, développer et déployer une solution Π en suivant le cycle en Y. Le projet porte également l'objectif d'automatiser la production du code à partir de la modélisation. Le cycle en Y se prête très bien au support de cet objectif.
Π[modifier | modifier le wikicode]
Le Pentagon Model est un modèle conceptuel qui a servi à l'élaboration des normes sur les échanges entre les back office pour gérer l'interopérabilité. Les références à ce modèle ont été supprimées des versions récentes des normes et remplacées par d'autres (ODP). J'ai retrouvé une vieille version de la norme 14904 version 2002 où le modèle conceptuel est présenté en annexe.
Fichier:ISO 14904-Annex Conceptual model.pdf
Le système Π[modifier | modifier le wikicode]
Le pentagon model[modifier | modifier le wikicode]
Etude sur le thème de la comptabilité dans le back office de péage/billettique[modifier | modifier le wikicode]
Υ[modifier | modifier le wikicode]
Le cycle de vie en Y se classe dans la famille des méthodologies qui ont été formulées après la publication d'UML, qui résulte elle même du consensus entre "les amigos" sur un plus petit commun multiple des propositions antérieures dans la champ des modèles à objets.
On pourra ajouter ici un ou des liens sur l'histoire d'UML
Rappelons-nous : UML n'est pas une méthode, c'est un langage. Une fois le langage défini, les gourous du domaine se sont attaqué à la formalisation de méthodes. La plus connue est sans aucun doute RUP (Rational Unified Process), mais RUP était un produit commercial et pour contourner les problèmes de licence de nombreuses société ont mis en place des méthodologies qui avaient l'odeur et la couleur de RUP mais ce n'était pas RUP.
La méthodologie, qui a le plus retenu mon attention est celle connue sous le nom de 2 Track Process, promue par Valtech. De nombreuses polémiques ont entouré son développement, basée au départ sur des travaux universitaires sa paternité est revendiquée par plusieurs personnes/sociétés. Peu nous importe aujourd'hui, ce que nous en retenons c'est le Y, qui la sous-tend.
Nous avons également été très influencés par les travaux de Ibtissem Hassine, qui pour réaliser sa thèse a formalisé la méthode Symphony dans le cadre d'une collaboration avec la société Umanis.
Le cycle en Y, se constitue de trois branches, comme la lettre Y majuscule. La branche de gauche est consacrée aux aspects fonctionnels, celle de droite aux aspects technique et la jambe du Y décrit l'implémentation de la fonction sur la technologie retenue.
Ce cycle est particulièrement adapté pour gérer les développements dans un domaine particulier où l'on fait des projets qui se ressemblent tous, sans être exactement la même chose. Le marché est trop petit pour justifier l'investissement dans le développement d'un produit. Ou bien la variablité est grande et demanderait un niveau de paramétrage du produit qui conduirait à un niveau de complexité exagéré.
Ce cycle présente également le meilleur support pour une démarche MDA, en effet il sépare bien les aspects et simplifie la problématique de traduction des modèles.
Le cycle en Y[modifier | modifier le wikicode]
La règle du jeu[modifier | modifier le wikicode]
La plate-forme collaborative[modifier | modifier le wikicode]
La plate-forme collaborative est un portail qui supporte le travail d'une équipe en mode étendu.
Le mode étendu signifie que les membres d'une équipe ne se rassemblent pas toujours dans le même lieu pour travailler sur le projet auquel ils contribuent.
Des rassemblements sont nécessaires, mais ils sont épisodiques et les activités sont séparées entre celles qui nécessitent d'être en face à face et celles qui peuvent être réalisée à distance.
Pour supporter le travail en mode étendu des outils sont nécessaires, l'ensemble de ces outils, rassemblées sur un portail unifié constituent le groupware de l'équipe. Il existe de nombreuses solutions de groupware en logiciel libre, mais je suis arrivé à la conclusion qu'aucun ne peut répondre à tous les besoins d'une équipe, les différents outils qui composent un portail de groupeware ont tous leurs points forts et leurs points faibles au regard du cahier des charges d'une équipe particulière. C'est pourquoi je préfère composer mon propre groupware et choisir les outils un à un.
Dans l'idéal, ces outils seront fédérés dans un portail unifié avec un gestion de droits unique au niveau du portail et une charte graphique commune.
J'ai tout d'abord établi la liste des outils que je veux voir dans mon portail pour une équipe qui ferait du développement logiciel.
Mon Portail de GroupWare[modifier | modifier le wikicode]
Expertise sur les outils[modifier | modifier le wikicode]
Expertise EA[modifier | modifier le wikicode]
FAQ EA[modifier | modifier le wikicode]
Expertise ECM ( Nuxeo)[modifier | modifier le wikicode]
Une video de présentation de Nuxeo en français : [1]