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.

Sujets des articles

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 les cas est un bon support de gestion de la road map dans le cas du développement d'un produit.

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

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 traçabilité

Dans la suite de la gestion des exigences vient la traçabilité.

EA propose des outils pour construire des matrices de traçabilité.

L'article présente les fonctions de EA pour gérer la traçabilité et fournit des exemples de rapports de traçabilité.

La gestion des tests

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.

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.

Mohamed : La spécification des tests

De nombreuses sources affirment que les modèles des uses cases donne directement le plan de test du système. L'article rend compte de l'expérience qui a été faite sur le projet de Hub et essaie d'en proposer un bilan.

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]