urbanisation-si

urbanisation-si

Expression des besoins


Expression des besoins : fini de bafouiller, articulez mieux vos exigences à vos éléments de modélisation dans MEGA

expression-des-besoins-diagramme-exigences-elements-modelisation-AGL-MEGA.png

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 :

  1. Dans l’espace de travail, cliquez sur Affichage > Fenêtres de navigation > Diagrammes.
  2. 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.
  3. Dans les menus du cadre Objet décrit, sélectionnez un projet.
  4. 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/

http://bonnes-pratiques-si.eklablog.com/

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


03/07/2015
0 Poster un commentaire

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

expression-des-besoins-modelisation-exigences-AGL-MEGA.png

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 :

  1. Positionnez-vous sur un projet.
  2. Dans son menu contextuel, sélectionnez Nouveau > Exigence.�
  3. 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 :  

 

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/

http://bonnes-pratiques-si.eklablog.com/

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


02/07/2015
2 Poster un commentaire

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

modelisation-expression-des-besoins.png
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/

http://bonnes-pratiques-si.eklablog.com/

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


23/06/2015
0 Poster un commentaire

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

Eriksson.gif

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/

http://bonnes-pratiques-si.eklablog.com/

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


20/06/2015
0 Poster un commentaire

Expression des besoins : Posez des questions efficacement

Expression des besoins : Les types de questions

expression-des-besoins-poser-des-questions.png

 

 
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

24/05/2015
0 Poster un commentaire