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

1 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 : 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 :

17/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case

Détails Cas d’Utilisation – UML – Diag. Use Case

Un use case UML ( cas d'utilisation ) est une activité métier comme par exemple un acte de gestion exécuté par un acteur externe à l'application.

Un acteur au sens UML du terme, est un rôle qui correspond à son activité métier au moment ou il utilise le système. Par exemple, un directeur commercial peut avoir plusieurs rôles au sein de l'application. Si celle-ci propose une fonctionnalité d'aide à la rédaction de propositions commerciales, lorsqu'il veut en rédiger une ( activité identifiée normalement dans la modélisation des processus métier ), il endosse le rôle de "rédacteur de proposition commerciale". Pour la gestion des prospects son rôle est alors "ingénieur commercial" et lorsqu'il souhaite gérer les tableaux de bord de ses commerciaux, "directeur commercial".

Ces rôles sont des profils fonctionnels par rapport à l'exercice d'une activité composée d'une suite d'actions.

Les acteurs sont identifiées à partir des fonctions existantes dans l'entreprise et à partir des processus métiers de la vue modélisation métier de l'urbanisation du Système d'Information.

Un use case comporte un ou plusieurs scénarios composés de une ou plusieurs étapes.

Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.

La bonne pratique est de toujours commencer par analyser les scénarios nominaux puis les décrire jusqu'à obtenir une version stable. Il est alors plus aisé d'identifier les scénarios alternatifs et exceptionnels à partir de la séquence normale des étapes des scénarios principaux.

Un scénario nominal conduit au résultat attendu, un scénario alternatif va mener à une fin normale mais en empruntant un autre chemin c'est à dire une autre suite d'étapes pour des conditions particulières, quand au scénario exceptionnel, il conduit toujours à une fin anormale correspondant à la génération d'une exception métier comme par exemple une donnée de paramétrage inexistante.

D'après l'ouvrage culte d'Alistair Cockburn "Writing effective use case", on peut définir 3 niveaux de use case qui sont pour reprendre son allégorie : le niveau nuage, le niveau de la mer et le fond de la mer.

Le niveau nuage correspond à des use case à fortes granularités, stratégiques comme par exemple "Gérer un prêt bancaire". Ces use case sont trop "gros", ils doivent être décomposés en use case du niveau de la mer.

Le niveau de la mer correspond bien à un use case utilisateur pour l'application cible, l'exemple précédent se décomposerait en 3 use case : "Gérer une demande de prêt bancaire", "Analyser une demande de prêt bancaire" et "Valider une demande de prêt bancaire".

Et le niveau fond de la mer, correspond à une fonction élémentaire simple non décomposable comme par exemple "Imprimer la demande de prêt bancaire". Ces use case correspondent à une simple étape d'un scénario.

Pour synthétiser, tout se résume à déterminer la bonne granularité d'un use case.

Alors comment faire pour trouver les bons use case, ni trop gros, ni trop fin ?

Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".

Un use case doit avoir en moyenne 10 scénarios composés chacun d'environ 10 étapes. De plus il doit être déclenché par un unique acteur ( rôle ), exécuté dans une limite de temps, être transactionnelle, avoir un début et une fin et pour terminer on doit avoir unicité de lieu.

Donc si ron eprend l'exemple du use case niveau nuage "Gérer un prêt bancaire", on voit qu'il faut d'abord faire une demande de prêt déclenchée par un chargé de clientèle, puis cette demande est analysée par un analyste financier et ensuite validée par le directeur d'agence.

Il y a donc 3 acteurs différents, intervenant à des moments différents dans des lieux éventuellement différents. Par conséquent, le use case doit être décomposé pour satisfaire la méthode des "10 ; 10".

Examinons cette décomposition.

La gestion de la demande exige environ une dizaine de scénarios ( utilisation, type de prêt, ... ) et pour chaque scénario on aurait approximativement une dizaine d'étapes ( situation de famille, recensement des revenus, existence d'autres prêts, même établissement, propositions de différentes solutions de remboursement, ... ). Le use case "Gérer une demande de prêt bancaire" est déclenché par un seul acteur le chargé de clientèle, il débute quand celui décide de créer/modifier une nouvelle demande et se termine quand celle-ci est créée ou modifiée.

Le use case "Analyser un prêt bancaire" est déclenché par l'analyste, commence lorsqu'il décide d'analyser une demande en attente et se termine lorsqu'il a émis une recommandation. On peut identifier une dizaine de scénarios constitués d'une dizaine d'étapes.

Le même raisonnement s'applique pour "Valider un prêt bancaire" déclenché par le directeur d'agence.

Si un même use case doit être factorisé et exécuté systématiquement dans plusieurs autres, on utilise la relation de dépendance <<include>>, du use case inclus vers celui qui le contient. Typiquement c'est le cas de l'authentification qui doit être obligatoirement effectuée au début de chaque use case.

Un use case peut être le prolongement d'un autre, on dit qu'il étend un use case ( relation <<extend>> attention au sens de la flèche qui va de celui qui étend vers celui qui est prolongé ). Par exemple, pour analyser une demande de prêt, il faut les rechercher et les consulter donc le use case "Analyser une demande de prêt" étend le use case "Rechercher et consulter une demande", sachant que l'on peut juste vouloir consulter sans faire d'analyse. L'appel au use case qui étend est donc facultatif.

On vérifie que toutes les exigences sont implémentées dans au moins un use case. Si ce n'est pas le cas c'est qu'on n'a pas encore terminé le travail de recensement des use case ou bien que les exigences restantes sont en dehors du périmètre de l'application.

Cette traçabilité est assurée par des relations d'implémentation UML allant de l'exigence modélisée comme une classe vers le use case.

Chaque scénario doit être décrit de manière textuelle en adoptant un formalisme qui constitue le modèle de fiche de use case. Les AGL offrent des modèles prêts à l'emploi. L'avantage est que cette description textuelle est stockée directement dans le référentiel de l'AGL. La traçabilité est ainsi assurée, on peut générer automatiquement la documentation et faire des estimations avec les modules de points de use case.

La méthode empirique d'identification des use case dite des "10 ; 10" a toujours donné de bons résultats et surtout permet d'avoir un cadre pour se prémunir des pièges lorsqu'on débute dans la modélisation des exigences et obtient donc une note de 10/10.

"La bonne musique ne se trompe pas, et va droit au fond de l'âme chercher le chagrin qui nous dévore."

Stendhal

Voir aussi :

16/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 13ème partie - Contexte Dynamique/Diag. Flux

Détails Contexte Dynamique/Diag. Flux – UML – Diag. Communication

En urbanisation des Systèmes d'Information ( SI ), les flux entre les différentes applications sont modélisés en UML par un diagramme de communication ( le fameux diagramme de flux cher aux Merisiens n'existe pas en UML ! ). De la même manière, on représente les flux entrants et sortants d'une application par ce type de diagramme UML.

La future application est considérée comme une boite noire. Les acteurs externes au système sont des objets qui envoient ou reçoivent des messages.

L'objectif n'est pas d'ordonner les messages, ce serait rentrer dans un degré de granularité beaucoup trop fin pour cette étape de la modélisation des besoins, mais à partir des acteurs, il s'agit d'identifier quelles demandes ils peuvent faire et ce qu'ils attendent du système en retour.

Ce modèle permet aussi de recenser ou de compléter les exigences identifiées soit à la modélisation métier, soit par les techniques standards d'analyse de documents, interviews, groupe de travail, ..., et prépare l'étape suivante qui consiste à rechercher et à décrire les cas d'utilisation ( use Case ) UML.

"La vie est ton navire et non pas ta demeure."

Alphonse de Lamartine

Voir aussi :

http://www.urbanisation-si.com/