Expression des besoins
Expression des besoins : fini de bafouiller, articulez mieux vos exigences à vos éléments de modélisation dans MEGA
Le diagramme d’objectifs et d’exigences explicite l’articulation entre :
- Les éléments concernés par un objectif ou contraints par une exigence.
- Les éléments qui contribuent à la réalisation d’un objectif ou à la satisfaction d’une exigence.
Pour créer un diagramme d’objectifs et d’exigences :
- Dans l’espace de travail, cliquez sur Affichage > Fenêtres de navigation > Diagrammes.
- Dans la fenêtre de navigation Diagrammes, cliquez avec le bouton droit sur le dossier "Diagramme d’objectifs et d’exigences" puis cliquez sur Nouveau > Diagramme. La fenêtre Création d’un diagramme d’objectifs et d’exigences apparaît.
- Dans les menus du cadre Objet décrit, sélectionnez un projet.
- Modifiez éventuellement le Nom du diagramme et cliquez sur OK. disponible dans l’onglet Général de la fenêtre de propriétés du diagramme. Le diagramme d’objectifs et d’exigences est créé.
Le projet Commande Livraison a pour objectif d’améliorer le processus Commande/Livraison. Cet objectif qualitatif est trop vague pour être opérationnel. Aussi le décompose-t-on en deux sous-objectifs quantitatifs qui présentent l’avantage d’être mesurables.
Le premier objectif est d’assurer un délai de livraison inférieur à 48 h dans 95 % des cas.
La procédure "Commande Livraison Urgente" et l’application "Gestion des transports" sont les principaux contributeurs potentiels à la réalisation de cet objectif.
Le deuxième objectif vise à préserver la qualité de fonctionnement du processus commande-livraison. C’est le magasin de produits finis qui doit assurer la conformité de la commande par rapport à la livraison, en particulier lorsqu’il traite les ordres de mouvements. L’indicateur utilisé pour vérifier ce bon fonctionnement est le taux de retour pour commande non conforme. On voudrait que ce taux demeure inférieur à 0,1%. La liberté de manoeuvre du chef du projet est restreinte par un certain nombre d’exigences qui ont été assignées dès le démarrage du projet.
Une première exigence est d’ordre technique : la répartition géographique des dépôts ne pourra pas être modifiée à l’occasion de ce projet. Cette exigence s’applique aux magasins de produits finis qui sont situés dans les dépôts.
La deuxième exigence est un choix organisationnel : les livraisons partiront toujours des dépôts. Elle sera à prendre en compte lors du traitement des ordres de mouvement avec l’application de gestion des transports.
La troisième est un choix d’entreprise : la livraison est toujours sous-traitée à des transporteurs externes car la société veut se concentrer sur son coeur de métier et ne veut pas se disperser dans des activités annexes. Cette exigence est à respecter dans la réorganisation de la procédure "Commande livraison urgente" et dans les modifications de l’application de gestion des transports.
Les objectifs peuvent être reliés à des problèmes de manière à indiquer la raison pour laquelle ils sont mis en oeuvre dans la stratégie de l’organisme.
Un problème est un fait empêchant d'atteindre des objectifs fixés et auquel il faut apporter une solution.
Les axes stratégiques permettent de classifier les objectifs selon leur nature et à représenter les enchaînements d’objectifs.
Un axe stratégique est une des dimensions suivant lesquelles une entreprise fonde sa vision et sa stratégie. Le Tableau de Bord Prospectif (Balanced Scorecard en américain) comporte quatre axes stratégiques qu'il convient d'équilibrer : finance, clients, processus internes et apprentissage organisationnel.
Un axe stratégique peut être placé dans un couloir afin d’améliorer la présentation graphique du diagramme.
"Mieux vaut une conscience tranquille qu'une destinée prospère. J'aime mieux un bon sommeil qu'un bon lit."
Victor Hugo
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
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
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Expression des besoins : Posez des questions efficacement
Expression des besoins : Soyez efficient dans l'organisation de vos groupes de travail !
- 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 ;
"Le meilleur moyen de se défaire d'un ennemi est de s'en faire un ami."
Henti IV
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Expression des besoins : Concevez des modèles de spécifications avant que ce ne soit trop tard !
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
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
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package
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 :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/