Sujets des articles
Emmanuel : Du modèle de classe au modèle de données[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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é[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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.