urbanisation-si.com

03/07/2015

0 J'aime 0 Poster un commentaire

Expression des besoins : modélisation des exigences avec le "mega extra super" AGL MEGA

L'Atelier de Génie Logiciel (AGL) MEGA permet de mettre en place un référentiel d'exigences.

La gestion des exigences est l’ensemble des activités qui permettent de s’assurer que les spécifications du client, c’est-à-dire les exigences, sont satisfaites.

Les exigences sont les contraintes qui pèsent sur le projet. Toute solution proposée pour atteindre l’objectif doit satisfaire aux exigences imposées.

Dans MEGA, pour disposer des exigences, depuis l’espace de travail, sélectionnez Outils > Options puis cliquez sur Modélisation des processus et de l’architecture. Dans la partie droite de la fenêtre, cochez la case Modélisation des objectifs et des exigences.

Un objectif est un but que l'on cherche à atteindre ou la cible visée pour un processus ou une opération. Il permet de mettre en évidence les points que l'on veut améliorer pour ce processus ou cette opération.

Un indicateur permet de préciser l'unité utilisée pour estimer dans quelle mesure on se rapproche d'un objectif fixé.

Une exigence est un besoin ou une attente formulés explicitement, imposés comme une contrainte à respecter dans le cadre d'un projet de certification, d'organisation ou de modification du système d'information d'une entreprise.

Pour créer une exigence dans MEGA :

Positionnez-vous sur un projet.
Dans son menu contextuel, sélectionnez Nouveau > Exigence.ï¿½
Dans la fenêtre de création d’une exigence, saisissez le nom de l’exigence et cliquez sur OK.

Il existe plusieurs types d’exigences :

Organisationnelle
Attente des clients
Système
Technique
Choix d’entreprise
Légale ou Réglementaire
(une) attente fomulés, habituellement implicites, ou imposés".

La norme ISO 9000 met en avant les "attentes des clients" mais dans le cadre d'un projet, d'autres exigences sont à considérer (par exemple les contraintes de la direction, le respect de recommandations, etc.)

Dans un diagramme, le type est rappelé dans la forme de l’exigence.

La priorité de l’exigence peut être :

Faible
Moyenne
Forte

Satisfaction de l’exigence, une procédure, une opération, une application, un service, etc. peuvent contribuer à la satisfaction d’une exigence.

Portée de l’exigence, il est possible de préciser quels éléments sont contraints par l’exigence.

"Placez votre main sur un poêle une minute et ça vous semble durer une heure. Asseyez vous auprès d'une jolie fille une heure et ça vous semble durer une minute. C'est ça la relativité."
Albert Einstein

Voir aussi :

02/07/2015

0 J'aime 2 Poster un commentaire

Expression des besoins : mais à quoi bon les modéliser ?

L'ingénieur des exigences ( expression des besoins ) est rompu aux techniques pour les identifier et les formaliser.

L'analyse des documentations diverses et variées, les techniques d'interview, l'animation de groupes de travail n'ont plus de secret pour lui.

Une fois l'expression des besoins rédigée dans la langue de Molière, une bonne pratique reconnue consiste à modéliser non pas dans la langue de Shakespeare mais dans celle de l'OMG c'est à dire en UML ou SysML.

L'excellent AGL Enterprise Architect offre un diagramme de requirement qui n'est ni plus ni moins qu'un diagramme de classe stéréotypé UML ou bien la même chose mais dans le dialecte SysML, lui même un profil normalisé UML.

Bon mais pourquoi faire ?

D'abord et cest ce qu'on trouve dans tous les bons bouquins traitant d'UML, un schéma vaut mieux qu'un long discours.

Ensuite on va pouvoir structurer les exigences par des compositions, des agrégations, des associations ou encore des dépendances.

L'objectif est de créer des relations entre les exigences pour mieux en maitriser la complexité.

L'AGL Enterprise Architect permet d'affecter des meta informations comme l'état de l'exigence, la priorité, le niveau de complexité, la version, la phase du projet, la date de création, l'auteur, ... Les états possibles sont : proposé, approuvé par la MOA, obligatoire, validé par la recette et enfin implémenté.

Et le meilleur pour la fin, les exigences modélisées sous forme de classe peuvent se retrouver dans n'importe quel diagramme pour être liées à dautres éléments de modélisation comme les use case.

Si on considère qu'un use case implémente des exigences alors on utilisera la relation UML d'implémentation du use case vers l'exigence.

Si par contre l'objectif est de tracer de bout en bout une exigence depuis son modèle en passant par tous les artefacts d'analyse, de conception jusqu'au modèle de code, on utilisera la relation de dépendance avec le stéréotype "trace" allant de la classe représentant l'exigence vers le use case qui la réalise.

Lorsqu'on met en place ce genre de relations, l'AGL Enterprise Architect propose une matrice de traçabilité qui n'est plus ni moins qu'un tableau ou les lignes représente la source et les colonnes la cible.

Concrètement il suffit dans le menu contextuel de choisir "Relation ship Matrix", d'indiquer le package source contenant les exigences et le package cible contenant les use case et automatiquement l'AGL affiche des croix aux intersections correspondant aux relations. On peut indiquer le type de relation (implémentation, dépendance, trace, ...) que l'on veut.

La modélisation des exigences permet donc de mesurer les impacts en cas de changements et de pouvoir prendre la décision si on fait évoluer ou pas et quels sont les modèles touchés, ce qui est vitale dans le monde qui nous entoure.

"Le bonheur est parfois caché dans l'inconnu."
Victor Hugo

Voir aussi :

23/06/2015

0 J'aime 0 Poster un commentaire

AGL (Atelier de Génie Logiciel) : les ministères recommandent Enterprise Architect de Sparx System

Une des bonnes pratiques pour un projet de réalisation d'une application informatique est de modéliser les aspects métiers, les besoins, l'analyse et la conception et pourquoi pas aller jusqu'aux modèles de code afin de le générer.

Pour disposer d'un référentiel partagé, de la gestion de version, de la traçabilité, de la génération de documentation et du code et que sais-je encore, il est obligatoire de mettre en place un outil appelé AGL (Atelier de Génie Logiciel).

Parmi les offres, "Enterprise Architect" de la société Sparx system se distingue par l'étendue de ses fonctionnalités, son excellent rapport qualité/prix et son ergonomie.

Cet outil est très certainement le modeleur UML/SysML/BPMN/ ... le plus convivial que je connaisse. Sa prise en main pour réaliser n'importe quel diagramme est quasi immédiate bien que les menus et options soient très nombreuses.

Un centre d'apprentissage (Learning Center), en plus de la traditionnelle "Aide" est disponible et permet d'avoir un tutoriel sur un sujet bien précis.

Tous les ministères ainsi que les organisations gouvernementales ont pour recommandation d'utiliser cet AGL disponible en différentes versions allant de la "standard" à la "ultimate" !

Donc si vous cherchez un outil de modélisation éprouvé, pas cher et convivial, n'hésitez plus, vous avez trouvé "bonheur" avec ce logiciel.

"Dans votre ascension professionnelle, soyez toujours très gentil pour ceux que vous dépassez en montant. Vous les retrouverez au même endroit en redescendant."

Woody Allen

Voir aussi :

20/06/2015

0 J'aime 0 Poster un commentaire

Expression des besoins : Posez des questions efficacement

Expression des besoins : Les types de questions

Une grille d'interview, préparée à l'avance, est utile. Elle contient des questions types à poser.

Les questions ouvertes permettent de comprendre le contexte de travail, et les besoins immédiats.

Ce sont des questions en « comment ». Par exemple, comment faites-vous actuellement pour enregistrer une demande de prêt ?

Les questions en « quoi » permettent de dérouler un processus : une fois que vous avez fini cette action, que faites-vous ?. Et ainsi de suite. Cette manière de procéder permet de recueillir les exigences du même niveau appartenant à une séquence.

Les questions en « comment » permettent d'apporter plus de détails : concrètement, comment faites-vous ? Ce type de question permet donc de descendre des exigences de haut niveau aux exigences opérationnelles.

Inversement, la question « pourquoi » est utile pour prendre de la hauteur.

Il est possible d'enchaîner les "pourquoi" pour remonter au niveau de besoin adéquat par rapport à l'objectif fixé.

Il nous faut une case à cocher "Type de prestation" ( expression d'une solution en terme d'interface utilisateur, beaucoup trop bas ).

Question : Pourquoi une case à cocher ?

Réponse : on doit pouvoir indiquer au système si les prestations versées sont de type "capital", "rente" ou "indemnité journalière" ( il s'agit là d'une exigence fonctionnelle, correctement formulée, mais sans doute encore de trop bas niveau ).

Question : Pourquoi doit-on pouvoir indiquer cela au système ?

Réponse : À tout moment, un gestionnaire qui interroge le dossier de prestation d'un assuré doit savoir de quelle type de prestation il s'agit.

En posant deux questions « pourquoi ? », on a ainsi trouvé une exigence globale, qui est un invariant du système à construire. Cela va sans dire, une exigence formulée de cette manière pose les bases d’un logiciel mieux construit et plus maintenable. L'exigence peut être spécifiée dans le cahier des charges.

En revanche, la question « pourquoi » posée à titre personnel est à proscrire, car elle peut être ressentie comme une agression. La première question de l’exemple précédent devient, en caricaturant « mais pourquoi voulez-vous à tout prix cliquer sur cette case ? »

Même sans aller jusque-là, une question « pourquoi » impliquant la personne interviewée doit être évitée.

"Le coup passa si près que le chapeau tomba

Et que le cheval fit un écart en arrière.

Donne-lui tout de même à boire, dit mon père."

Victor Hugo

La légende des siècles

Voir aussi :

24/05/2015

0 J'aime 0 Poster un commentaire

Expression des besoins : Soyez efficient dans l'organisation de vos groupes de travail !

Ne sous estimez pas la préparation des réunions d'un groupe de travail !

La méthode naturelle, qui consiste à réunir des volontaires des différentes parties prenantes et à leur demander d'exprimer les besoins, est aussi la moins efficace.

Ainsi, en réunissant vingt personnes de métiers très différents, en mélangeant utilisateurs, donneurs d'ordres, maîtres d'ouvrage, et autres parties intéressées, on risque de ne recueillir que peu d'informations, et très peu d'exigences exploitables.

D'une part, par ce qu'au-delà de dix ou douze participants, une grande partie d'entre eux sera inactive et risquera même de perturber les autres, et d'autre part, par ce qu'il est difficile de défricher le terrain, d'écouter tous les besoins, et d'obtenir un consensus dans un milieu trop hétérogène.

Une méthode des plus efficientes consiste à réunir les parties prenantes par profil : une première réunion avec le maître d'ouvrage stratégique, puis une réunion avec des représentants des utilisateurs d'un métier, puis d'un autre métier.

Une fois que les besoins des différents contributeurs seront recueillis, on programmera une réunion mixte avec le représentant de chaque métier ou profil utilisateur.

De tels ateliers peuvent également réunir maîtrise d'ouvrage et maîtrise d‘œuvre, ou utilisateurs et développeurs, dans un même lieu.

L’animation de ces ateliers de travail, qui peuvent durer plusieurs jours n'est pas chose aisée.

Au moins deux animateurs sont nécessaires : I'analyste ou assistant à la maîtrise d'ouvrage, et une personne chargée de prendre des notes et de les organiser.

Les ateliers sont sans doute le moyen le plus puissant de recueillir les besoins, mais ils demandent un important travail de préparation, de la part de tous les participants, mais surtout de la part de l'animateur.

De plus, certaines règles doivent impérativement être respectées :

choisir avec soin un nombre limité de participants (quatre à cinq, plus les animateurs) ;
faire respecter une bonne discipline de travail à tous les participants :
arriver à l'heure, éteindre son téléphone mobile, éviter toute conversation en aparté, respecter les divers avis ;
rester aligné avec les objectifs tels qu'ils ont été formalisés ;
maintenir la discussion au bon niveau de détail ;
éviter de descendre trop dans les détails, ou au contraire de remettre en cause les objectifs ;
si de nouvelles idées apparaissent et semblent intéressantes, éviter de dévier, mais conserver ces idées à part, de manière à y revenir plus tard, lors d'un autre atelier par exemple ;
fixer un ordre du jour précis, avec une durée précise pour chaque point, et s'y tenir ;

L'idéal est presque d'arriver à faire un "one man show" pour maintenir jusqu'au bout I'enthousiasme du début.

"Le meilleur moyen de se défaire d'un ennemi est de s'en faire un ami."

Henti IV

Voir aussi :

24/05/2015

0 J'aime 0 Poster un commentaire

Expression des besoins : Concevez des modèles de spécifications avant que ce ne soit trop tard !

Un piège de la gestion de projet, c'est croyant faire des économies au départ , on se retrouve pa la suite à tout recommencer alors qu'il aurait fallu un peu d'outillage et de méthode.

L'urbanisme du Système d'Information offre un cadre de développement lui permettant d'être agile, flexible, évolutif et facilement maintenable.

La mise en place de modèles de spécification permet d'avoir une uniformisation et une homogénéité de l'ensemble des projets à venir.

L'avantage se situe au niveau réutilisabilité et permet d'éviter les pièges.

Dans un projet d'envergure, par exemple, aucun modèle de spécification batch n'existait et ce malgré les recommandations des consultants. Alors chacun a réalisé ses SFD à sa sauce. Certain ont spécifié très en détails avec leur expérience d'ancien coboliste. Ansi dans les spécifications fonctionnelles, on retrouvait la création de fichiers temporaires qui devaient être fusionnés suivant des règles complexes.

Malheureusement l'architecture cible choisie pour les traitements de masse était Spring Batch. Avec ce choix, il est plus facile d'utiliser des tables temporaires plutôt que des fichiers. Résultat des semaines de spécifications à refaire et en plus cela à aggraver les relations entre le client ( MOA ) et son fournisseur ( MOE ).

Un projet comporte bien trop d'aléas pour qu'on n'en ajoute pas d'avantages. Bien au contraire, il faut consacrer toute son énergie pour tout ce qui va faire économiser des charges comme les outils et les méthodes même si cela paraît contraignant car après il sera trop tard.

"La liberté consiste moins à faire sa volonté qu'à ne pas être soumis à celle d'autrui."

Jean-Jacques Rousseau

Voir aussi :

22/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance

Détail Traçabilité – UML – Relation de dépendance ( <<implement>> ) : les use case implémentant les processus métiers

Détail Traçabilité – UML – Relation de dépendance ( <<trace>> ) : les exigences doivent se retrouver dans au moins un Use Case

La modélisation du Système d'information ( SI ) avec un AGL ( Atelier de Génie Logiciel ) permet de mettre en place la traçabilité des entités appartenant au système.

L'urbanisation du SI s'attache à partir de la vue stratégique à dire que la vue métier doit être une implémentation des objectifs stratégiques. Chaque processus métier doit réaliser un ou plusieurs objectifs stratégiques.

De même dans le POS ( Plan d'Occupation des Sols ou vue fonctionnelle ), chaque bloc fonctionnel doit implémenter un ou plusieurs processus ou activité métier.

Et ainsi de suite pour la vue applicative ou chaque bloc applicatif réalisent un ou plusieurs blocs fonctionnels et pour la vue infrastructure ou les blocs exécutent un ou plusieurs blocs applicatifs ( applications, ... ).

Toutes ces vues peuvent se modélisées en UML ( Unified Modeling Language ) qui est très générique et qui permet de modéliser tout ce qu'on désire.

Les relations de dépendances UML permettent de mettre des liens entre tous les éléments de modélisation quel qu’ils soient.

Et on peu continuer ainsi jusqu'au projet d'une nouvelle application prévu par le POS par un bloc applicatif. Les besoins ou exigences correspondent aux entrées/sorties modélisées dans les activités des processus métier à automatiser ( stéréotypés <<automatisé>> ).

Une relation de dépendance va du ou des use case vers l'activité métier du diagramme d'activité qu'il(s) implémente(nt).

Une relation de dépendance va d'une exigence ( classe UML stéréotypée <<requirement>> ) vers un ou plusieurs use case.

Les messages systèmes des diagrammes de séquence des scénarios dépendent des use case.

Et ainsi de suite, la discipline "Analyse et Conception" dépend de la discipline "Expression des besoins (exigences)" qui dépend de la discipline "Implémentation", ...

Un surcoût indéniable est à prévoir pour mettre en place les liens de dépendance entre tous les artefacts de modélisation en partant du niveau le plus haut ( urbanisme du SI ) jusqu'aux modèles de codes ( diagrammes de classe, d'état et de séquence d'implémentation ) pour la génération de codes.

Le ROI sera au rendez-vous dès que l'on aura des modifications ou des évolutions. L'AGL permet alos de mesurer tous les impacts et de les chiffrer.

La génération automatiques de ces métriques apportent une aide primordiale à la prise décision pour savoir si on intègre un changement ou si on le diffère voir carrément refuser de le faire parce que les impacts sont trop importants et que cela engendrerait trop de risques et un surcoût inconsidéré.

"Il vaut mieux subir l'injustice que la commettre."

Socrate

Voir aussi :

18/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 16ème partie - Scénarios Cas d’Utilisation – UML – Diag. Séquence

Détails Scénarios Cas d’Utilisation – UML – Diag. Séquence

Une fois les use case identifiés, le diagramme réalisé et les scénarios rédigés, il est facile de les modéliser avec un diagramme de séquence UML.

La méthode est de faire un diagramme par use case s'ils sont simples ou s'ils comportent peu de scénarios ou bien un diagramme par scénario.

Le mode de pensée de ce modèle est de voir le système comme une boite noire, chaque action de l'utilisateur décrite dans la fiche de use case devient un message envoyé au système avec éventuellement sa réponse.

Il ne faut surtout pas chercher pas à modéliser le fonctionnement interne du système.

La vue en boite blanche, c'est à dire la conception de la solution à la requête de l'utilisateur sera réalisée à la discipline suivante "Analyse et Conception". Pour chaque message reçu, on déterminera alors la séquence de messages à envoyer aux contrôleurs et aux entités.

Cette modélisation fera l'objet d'un prochain article.

Ces diagrammes systèmes permettent de mettre l'accent sur les messages systèmes. L'objectif est de formaliser les comportements attendus du système considéré comme une boite noire.

La traçabilité des messages reçus par le système et auxquels il devra répondre sera assurée par les diagrammes de séquence de conception avec comme point d'entrée chacun des messages, le système étant remplacé par un contrôleur.

Attention au piège d'utiliser trop de raffinements UML des diagrammes de séquence réservés à la conception, au développement et à la génération de code. Ces modèles doivent rester lisibles par la MOA/MOAD.

"Plus contagieuse que la peste, la peur se communique en un clin d'œil."

Nicolas Gogol

Voir aussi :

18/05/2015

0 J'aime 1 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package

Détails Regroupement par Domaines – UML – Diag. Package : Acteurs et Use Case

Les use case sont des cas fonctionnels, qui doivent être regroupés par appartenance au même domaine fonctionnel correspondant en urbanisation du Système d'Information ( SI ) à un quartier du Plan d'Occupation des Sols (cartographie fonctionnelle).

En UML, l'élément de modélisation permettant de regrouper des entités est le package ( symbole de dossier ). On peut avoir plusieurs niveaux d'imbrication mais les règles d'urbanisme du SI font qu'on se limite à 3 ou 4 niveaux maximum sinon cela devient ingérable et surtout incompréhensible pour le commun des mortels.

Les package de cas d'utilisation permettent de structurer le comportement fonctionnel d'un système pendant la modélisation des exigences. On les nomme de manière compréhensible par les experts métier.

Les packages offrent donc la possibilité de travailler à différentes échelles suivant le profil du lecteur et le niveau de détails souhaité.

De la même manière les acteurs peuvent être rassemblé dans des packages.

Les dépendances fonctionnelles sont matérialisées par les relations de dépendance UML.

UML propose d'autres raffinements comme les dépendances <<use>> ou <<merge>> réservées aux packages de classes de conception et de compilation donc à ne surtout pas utiliser ici.

Afin d'avoir une architecture fonctionnelle évolutive et réutilisable, on devrait éviter autant que faire se peut, les dépendances bidectionnelles et cycliques ( A dépend de B qui dépend de C qui dépend de A ) qui conduit à terme à un système en mauvaise santé pour ne pas dire à un véritable plat de nouilles.

"La vie serait impossible si l'on se souvenait, le tout est de choisir ce que l'on doit oublier."

Roger Martin du Gard

Voir aussi :