|
|
| Ligne 1 : |
Ligne 1 : |
| | =[[Le projet PY]]= | | =[[Le projet PY]]= |
| − | =Présentation=
| |
| − | '''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.
| |
| − | ==ΠΥ==
| |
| − | ΠΥ est l'association de la lettre Π (pi) qui symbolise le pentagon du pentagon model qui est à la base de la conception des systèmes 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.
| |
| − | <---=La règle du jeu=
| |
| − | ---!>
| |
| − |
| |
| − | =Π=
| |
| − | 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 vielle version de la norme 14904 version 2002 où le modèles conceptuel est présenté en annexe.
| |
| − |
| |
| − | [[Fichier:ISO_14904-Annex_Conceptual_model.pdf]]
| |
| − | ==[[Le système Π]]==
| |
| − |
| |
| − | ==[[Le pentagon model]]==
| |
| − | [[Image:Processus_Y.jpg|thumb]]
| |
| − |
| |
| − | =Υ=
| |
| − | 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és 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 [http://www.valtech.fr 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é [http://www.umanis.com/ 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 processus de développement|Le cycle en Y]]==
| |
| − | ==[[Le reporting et la BI]]==
| |
| − |
| |
| − | ==[[Pratique de la modélisation]]==
| |
| − | Ce chapitre justifie la pratique de la modélisation et pose les trois concepts de base : langage - méthode - outil.
| |
| | | | |
| | =La plate-forme collaborative= | | =La plate-forme collaborative= |
La plate-forme collaborative
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és sur un portail unifié constitue 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.
Cette rubrique consigne la veille sur les outils qui pourraient être intégrés pour constituer la plate-forme infrastructure de support du travail d'une équipe projet en mode étendu.
Le portail de groupWare doit centraliser la gestion des utilisateurs et des droits. Un annuaire au standard LDAP est à mettre en place, d'où la nécessité d'acqguerrir l'expertise sur ce standard.
Expertise sur les outils
Nouvelle rubrique ouverte le 18-01-2014.
WP est la fois très populaire et de mon point de vue très difficile à maitriser.
Il n'y a pas de documentation utilisateur ou bien je ne sais pas où elle est.
https://codex.wordpress.org/Main_Page ?
Utilisation de MediaWiki
Consultez le Guide de l’utilisateur pour plus d’informations sur l’utilisation de ce logiciel.
Démarrer avec MediaWiki