Différences entre versions de « Le projet PY »

De TIc-siT_wiki
Sauter à la navigation Sauter à la recherche
m (1 révision importée)
 
(39 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 
=Présentation=
 
=Présentation=
 +
<!--
 +
-->
 
'''Ceci n'est pas''' un jeu, '''c'est''' un serious game !
 
'''Ceci n'est pas''' un jeu, '''c'est''' un serious game !
  
Vous allez découvrir le projet PY.
+
Vous allez découvrir le projet ΠΥ.
  
 
Voici en quelques mots de quoi il s'agit.
 
Voici en quelques mots de quoi il s'agit.
Ligne 9 : Ligne 11 :
  
 
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.
 
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]]=
 +
Ce chapitre justifie la pratique de la modélisation et pose les trois concepts de base : langage - méthode - outil.
 +
 
=ΠΥ=
 
=ΠΥ=
=Π=
+
ΠΥ 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.
=Υ=
 
  
=La règle du jeu=
+
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.
  
=[[Sujets des articles]]=
+
=Π=
==Emmanuel : Du modèle de classe au modèle de données==
+
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.
  
Lors de la phase de début de cycle on procède au recueil de besoin et à l'analyse des exigences. On identifie les acteurs, les processus, les objets du domaine. Les objets du domaine sont représentés dans des classes et leurs relations dans des diagrammes de classe. Ils sont identifiés dans le modèle des objets du domaine en vertu de la règle qui dit que tout objet du monde réel est a priori candidat à devenir un objet dans le SI en cours de conception. Mais a priori seulement car entre la phase d’ingénierie des exigences et la conception du système un travail d'abstraction va intervenir qui aura pour résultat le modèle de données dans le SI où l'on ne retrouvera pas un pour un les objets du monde réel. Deux raisons à celà : la vie du SI peut nécessiter la création d'objets à vocation technique sans correspondant dans le monde réel, on peut donner comme exemple tout ce qui sert à superviser le système : logs, colonnes d'audit dans les tables. La seconde raison se trouve dans les règles de construction des SI et dans l'application de design pattern nécessaires à une gestion rigoureuse des objets en tant qu'objets dans le SI et non plus dans le monde réel. On peut donner ici comme exemple le fait qu'un objet du monde réel sera projeté sur plusieurs tables que des champs de statut serviront à gérer le cycle de vie de l'objet que des tables servent à gérer les liaisons many to many, ...
+
[[Fichier:ISO_14904-Annex_Conceptual_model.pdf]]
L'article explique sur l'exemple de la gestion clientèle la démarche qui conduit d'un modèle de classes de très haut niveau à valeur uniquement documentaire établi en phase de recueil de besoin au modèle de la base de données relationnelle.
+
==[[Le système Π]]==
==Marc : L'intégration de BPMN dans l'ensemble des diagrammes utilisés dans la modélisation==
 
  
Notre parti pris méthodologique initial est d'utiliser la proposition UML, telle qu'elle est formulée par ses promoteurs, sans extensions parce que les extensions peuvent la rendre encore plus complexe alors qu'elle l'est déjà plutôt trop et diminuer l'effet vocabulaire commun d'UML. Pour des raisons qu'il serait intéressant mais trop long de mettre en lumière BPMN jouit d'une popularité que l'on ne peut pas ignorer et apporte des plus importants (selon moi) qu'il faut intégrer en relation à un objectif de long terme d'automatiser la production du code à partir de la modélisation. BPMN se définit comme un langage de description des processus et contient dès le départ le projet de pouvoir être interprété par des moteurs de work flow. Il présente des qualité graphiques et esthétiques qui rendent la documentation que l'on fait avec facile d'accès pour les clients, plus facile c'est certain que les diagrammes UML.
+
==[[Le pentagon model]]==
L'article présente l'apport de BPMN dans un corpus composé uniquement au départ d'un sous ensemble des diagrammes UML et comment après quelques mois de pratiques nous sommes amenés à proposer d'abandonner les diagrammes d'activité au profit des diagrammes BPMN.
+
[[Image:Processus_Y.jpg|thumb]]
==Paul : La gestion des exigences et autres==
+
==[[Etude module FIN|Etude sur le thème de la comptabilité dans le back office de péage/billettique]]==
Paul qui a travaillé plus que d'autres a pu accéder à l'expertise sur plusieurs sujets. Il pourra choisir par quel sujet commencer.
 
===La gestion des exigences===
 
EA propose des moyens pour la gestion des exigences, elles peuvent être classées, reliées entre elles. Elles constituent le point de départ de la gestion de la traçabilité.
 
  
Les tenants du développement agile ne sont certainement pas passionnés par ce sujet, mais si l'on doit conduire un projet "type ISO 9000" ou dans un contexte contractuel dur on peut être confronté à la nécessité de gérer la traçabilité de bout en bout de la couverture des exigences du contrat par la fourniture matérielle et logicielle qui résulte de la réalisation du contrat.
+
=Υ=
 +
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.
  
Quoi qu'il en soit, une gestion même partielle des exigences peut contribuer à une bonne structuration d'un projet et dans tous les cas est un bon support de gestion de la road map dans le cas du développement d'un produit.
+
On pourra ajouter ici un ou des liens sur l'histoire d'UML
  
La gestion des exigences distingue les exigences fonctionnelles qui renvoie aux fonctionnalités que devra fournir le système et les exigences non fonctionnelles qui portent d'une part sur les performances (volumes à gérer, temps de réponse) et sur des qualités que doit présenter le système pour tenir compte des objectifs du client : évolutivité, extensibilité, ...
+
''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.
  
L'article présente les fonctions disponibles dans EA pour gérer les exigences, créer des documents sur les exigences et les liens avec les étapes suivantes du cycle de vie, particulièrement les uses cases.
+
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.
  
===La traçabilité===
+
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].
Dans la suite de la gestion des exigences vient la traçabilité.
 
  
EA propose des outils pour construire des matrices de traçabilité.
+
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.
  
L'article présente les fonctions de EA pour gérer la traçabilité et fournit des exemples de rapports de traçabilité.
+
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é.
  
===La gestion des tests===
+
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.
Mohamed a travaillé sur la spécification des test à partir des uses cases.
 
  
Cette spécification représentée dans EA fournit un support pour faire le suivi de la réalisation des tests. C'est une partie de l'outil qui n'est pas directement dans le domaine d'UML et de la modélisation mais qui s'appuie sur elle et nous propose un outil qui en première approche permet de gagner beaucoup de temps et de disposer sans effort d'un reporting très précis et détaillé sur le déroulement des tests.
+
=[[Le processus de développement|Le cycle en Y]]=
  
L'article présente cet outil intégré à EA, la manière de l'utiliser et le type de reporting que l'on peut en tirer.
+
=La règle du jeu=
  
==Mohamed : La spécification des tests==
+
=La plate-forme collaborative=
De nombreuses sources affirment que les modèles des uses cases donne directement le plan de test du système.
+
La plate-forme collaborative est un portail qui supporte le travail d'une équipe en mode étendu.
L'article rend compte de l'expérience qui a été faite sur le projet de Hub et essaie d'en proposer un bilan.
 
 
 
==Cosmin==
 
 
 
=Mon GroupWare=
 
J'appelle GroupWare le 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.
 
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.
Ligne 70 : Ligne 64 :
 
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.
 
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]]==
 
==[[Mon Portail de GroupWare]]==
 +
 +
=Expertise sur les outils=
 
==[[Expertise EA]]==
 
==[[Expertise EA]]==
==[[FAQ EA]]==
+
 
 +
===[[FAQ EA]]===
  
 
==Expertise ECM ( Nuxeo)==
 
==Expertise ECM ( Nuxeo)==
 
Une video de présentation de Nuxeo en français : [http://www.youtube.com/watch?v=kPvtbb3VZOU&list=UUdSyfnniFpvGA1sRjtPYaBA&index=8&feature=plpp_video]
 
Une video de présentation de Nuxeo en français : [http://www.youtube.com/watch?v=kPvtbb3VZOU&list=UUdSyfnniFpvGA1sRjtPYaBA&index=8&feature=plpp_video]

Version actuelle datée du 6 mai 2016 à 12:58

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]

Erreur lors de la création de la miniature : Fichier manquant

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]