Le projet PY

Présentation

Ceci n'est pas un jeu, c'est un serious game !

Vous allez découvrir le projet PY.

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.

Pour donner l'accès à cette plate-forme je demande à chacun une contribution sous la forme d'un article sur un sujet sur lequel il a déjà un bon niveau d'expertise, en contrepartie de cette contribution je donnerai l'accès à la plate-forme. Dans la forme la contribution est un article de wiki ou un document Word illustré éventuellement de diagrammes EA qui seront reportés dans le modèle. Je me chargerai de la mise en forme et l'importation dans le wiki. La langue est l'anglais ou le français. Ceux qui se sentent à l'aise doivent préférer l'anglais mais cela ne doit pas se faire au détriment du fond.

Voici le sujet que j'ai déterminé pour toi :

Emmanuel : Du modèle de classe au modèle de données

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, ... 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.

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. 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.

Paul : La gestion des exigences et autres

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.

Quoi qu'il en soit, une gestion même partielle des exigences peut contribuer à une bonne structuration d'un projet et dans tous els cas est un bon support de gestion de la road map dans le cas du développement d'un produit.

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.

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.

Expertise ECM ( Nuxeo)

Une video de présentation de Nuxeo en français : [1]