urbanisation-si.com

16/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique

Détails Exigences– UML – Profil spécifique : exemples d'exigences fonctionnelles

Exemple d'exigences non fonctionnelles

Si dans une démarche d'urbanisation du Système d'Information ( SI ), on a cartographié la vue métier, les changements dans les processus métiers qu'ils s'agissent de modifications de nouveautés, vont conduire dans le schéma directeur à des nouveaux projets dont les exigences en seront directement issues.

Les AGL ( Atelier de Génie Logiciel ), utilisent des stéréotypes UML, c'est à dire une spécialisation de certains artefacts de modélisation. Pour les exigences, une classe UML est stéréotypée "Requirement" ( Exigence ) avec comme symbole de représentation un rectangle avec une double barre verticale dans le premier tiers gauche du rectangle.

Le modélisateur utilise alors les relations du diagramme de classe comme les associations, agrégations, compositions et héritages.

L'intérêt de l'AGL, c'est d'avoir un référentiel de tous les éléments de modélisation y compris les exigences. Un ensemble d'informations comme le titre, la description, le type ( fonctionnelle ou non fonctionnelle ), l'auteur, la date mais aussi des informations concernant la conduite de projet comme la priorité, le niveau de difficulté, la phase, les documentation liés, les règles, les contraintes, ... Toutes ces informations serviront par exemple à la planification, à la génération automatique de la documentation, ...

Exigences non fonctionnelles : la norme ISO/CEI 25000

Outre de pouvoir gérer un référentiel d'exigences, l'AGL permet, comme les exigences sont d'un point de vue UML des classes, de créer des liens de dépendances vers d'autres éléments de modélisation comme les activités du diagramme d'activité UML, celles des processus métier modélisés en BPMN.

Les cas d'utilisation ( Use Case ) modélisent les comportements attendus des futurs utilisateurs et auront des liens de dépendance ( on peut utiliser la relation UML d'implémentation ) vers les exigences.

On vérifiera ainsi que toutes les exigences sont implémentées par au moins un cas d'utilisation. S'il reste des exigences non implémentées, c'est soit que tous les use case n'ont pas encore été identifiés, soit qu'elles appartiennent à des fonctionnalités hors du périmètre projet.

"Une vie qui n'est pas réfléchie ne vaut pas d'être vécue."

Socrate

Voir aussi :

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

16/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package

Détails Liste des exigences – UML – Diag. Package

Après avoir voyagé au pays de la modélisation métier, nous voici arrivé aux étapes qui vont conduire à l'informatisation des activités métiers identifiées (ou stéréotypées UML) à automatiser.

La discipline "Exigence" (au sens UP Unified Process) ou "Expression des besoins" du futur système informatique nécessite de pratiquer un ensemble de techniques comme l'analyse documentaire, les interviews, les groupes de travail, ... Le résultat constitue la base d'analyse pour recenser et structurer les exigences.

Du reste dans de nombreux projets, on commence directement par l'expression de besoins sachant que la discipline précédente de modélisation métier n'est pas réalisée.

Toutes les entreprises ne décident pas de mettre en place une démarche d'urbanisation du Système d'Information. Le chef de projet risque de se retrouver démuni sans méthode éprouvée, sans les cartographies métiers, fonctionnelles, applicatives et d'infrastructures. Ces études permettent , ne l'oublions pas, de simplifier les études préalables et fournissent le contexte au projet et bout du compte engendre des économies substantielles.

Utiliser un AGL pour modéliser les exigences offrent les avantages suivants :

la gestion d'un référentiel centralisé d'exigences qui est sous contrôle (droits, mesures d'impacts en cas d'évolution, ...)
l'utilisation de profils UML inclus dans l'AGL et spécifiques pour les exigences. On n'a pas à créer ses propres stéréotypes par exemple.
la mise en place d'un AGL pour l'ensemble du projet, voir pour l'ensemble de l'urbanisation du Système d'Information de l'entreprise permet de centraliser l'ensemble des modèles et d'assurer la traçabilité entre les artefacts de modélisation, ce qui permet de mesurer immédiatement via l'outil les impacts d'un changement dans les exigences.

Mes retours d'expérience dans divers projets aussi bien dans le domaine public que privé, m'ont montré qu'il était important d'outiller et de mettre en place la bonne méthode adaptée à l'organisation et cela sans attendre les avancées des projets même si ça peu paraître coûteux au départ. Les processus métier peuvent vite évoluer et c'est le prix à payer si on veut être efficient dans l'agilité et la flexibilité.

"Ceux qui rêvent éveillés ont conscience de mille choses qui échappent à ceux qui ne rêvent qu'endormis."

Edgar Allan Poe

Voir aussi :

15/05/2015

1 J'aime 0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 1ère partie - Vue globale

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Vue globale

En urbanisation des SI, la vue métier supporte la vue stratégie. Ce sont les processus métier qui vont réaliser les objectifs stratégiques de hauts niveaux de l'entreprise.

La modélisation métier consiste à connaître et comprendre les processus métiers dans lesquels va s’intégrer la future application.

Il s’agit à ce niveau d’identifier les acteurs métiers, les processus et les entités métiers qui composent le domaine fonctionnel dont la future application fera partie. Les concepts métier sont modélisés sous forme de classes. La description des processus métier permet de définir précisément le périmètre que couvrira l'application, c’est-à-dire les activités qui vont faire l’objet d’une automatisation, les futurs Cas d'Utilisation.

Une fois connu, les activités à automatisées, les besoins sont modélisés. On recense toutes les exigences. On représente le contexte d’utilisation : le système vu comme une boîte noire et les acteurs qui interagissent avec lui (contexte statique). Ensuite on décrit les services rendus aux différents utilisateurs sous forme de cas d’utilisation. Il est possible de compléter ces descriptions par des représentations de la dynamique des échanges de messages entre le système et les utilisateurs (contexte dynamique).

La suite relève de la discipline (au sens Unified Process) Analyse et Conception qui donne une vision concrète du futur système grâce à une maquette et à la modélisation de l'architecture applicative.

"Un problème sans solution est un problème mal posé."

Albert Einstein

Voir aussi :

08/05/2015

0 J'aime 0 Poster un commentaire

Modélisation des besoins : qu'est ce je dois faire et ne pas faire ?

Les 9 disciplines et les 4 phases de la méthode de gestion de projet UP (Unified Process)

L'urbanisation SI est une démarche fractale. Les techniques utilisées s'applique au SI, puis aux projets,..., jusqu'au composants et objets des applications. La première méthode itérative de gestion de projet, UP (prononcer youpie) pour Unified Process propose 9 disciplines qui s'apparentent aux 5 vues de l'urbanisme SI. La discipline Business Modeling ou Modélisation Métier s'intéresse aux processus metiers et permet de modéliser les acteurs et les activités à automatiser. Soit on utilise les diagrammes d'activité UML brut de fonderie ou mieux des profils UML comme Eriksson Penker ou bien encore le langage spécialement conçu pour les experts métier BPMN. C'est le point d'entrée de la discipline suivante Requirement ou Exptession des besoins. Les activités à automatiser deviennent les uses case qui représentent les comportements attendus de la future application. Les données métier sont représentées avec un diagramme de classe ou chaque classe comporte juste des attributs et les relations. Les scénarios sont modéliser avec des diagrammes de séquence. Le système est considéré comme une boite noire. Les états et les transitions doivent être modélisés avec un diagramme d'état. Ca c'est-ce que doit modéliser la MOAD (Maîtrise d'Ouvrage Déléguée).

Maintenant voyons un peu ce qu'on ne doit pas faire. La MOAD ne doit pas faire des modèles complexes, détaillés, utilisant des techniques de modélisation trop sophistiquées, faire des modèles surchargés illisibles et anticiper sur les solutions techniques et l'optimisation. La MOE ne doit pas quand elle se contenter de réécrire le cahier des charges. UP prévoit une discipline Analyse et Conception pour que la MOE affine les modèles de l'expression des besoins avec les concepts objets, services, composants, intègre le projet dans le POS du cadre d'urbanisme SI. La aussi, on doit être agnostique sur le plan technologie.

Quand à la direction générale elle ne doit pas laisser faire sans s'impliquer et dire dans le cas ou le projet échouerait c'est la faute à la DSI ce qui relèverait de la part de la DG d'une totale incompétence.

"Il est des entreprises pour lesquelles la vraie méthode est un désordre intentionnel."

Herman Melville

Voir aussi :

04/05/2015

0 J'aime 0 Poster un commentaire

Modéliser l'expression des besoins pour vous éviter de vous retouver avec un lave vaisselle alors que vous vouliez un lave linge !

Analyser le problème

Identifier le vocabulaire commun
Développer la vision
Touver les acteurs et les Use Cases
Développer le plan de gestion des spécifications
Artefacts produits ou modifiés :
- Glossaire
- Vision
- Modèle de Use Case
- Plan de gestion des spécifications

Comprendre les besoins des intéressés

Identifier le vocabulaire commun
Développer la vision
Touver les acteurs et les Use Cases
Identifier les besoins non fontionnels (FURPS+)
Identifier les besoins fonctionnels
Gérer les dépendances (traçabilité)
Artefacts produits ou modifiés :
- Glossaire
- Vision
- Modéle des besoins non fontionnels (FURPS+)
- Modèle des besoins fonctionnels
- Modèle de Use Case
- Spécifications supplémentaires

Définir le système

Développer la vision
Identifier le vocabulaire commun
Touver les acteurs et les Use Cases
Gérer les dépendances (traçabilité)
Artefacts produits ou modifiés :
- Glossaire
- Modèle de Use Case
- Spécifications supplémentaires

Gérer le périmètre du système

Développer la vision
Délimiter les frontières du système
Donner des priorités aux Use Cases
Artefacts produits ou modifiés :
- Vision
- Liste des Use Case avec les priorités

Affiner la définition du système

Affiner le modèle de Use Case
Ajouter les relations entre Use Case
Détailler les Use Cases
Détailler les besoins du futur système informatique
Modèliser l'interface utilisateur
Prototyper l'interface utilisateur
Revue de validation
Artefacts produits ou modifiés :
- Supplément de spécifications
- Fiche détaillée avec les scénarios des Use Cases
- Prototype d'interface utilisateur
- Liste des exigences
- Compte-rendu de la revue

Gérer les changements d'exigences

Gérer les dépendances (traçabilité)
Revoir les demande de changements
Revoir les exigences
Restructurer le modèle de Use Case
Revue de validation
Artefacts produits ou modifiés :
- Modèle de Use Case
- Compte-rendu de la revue

"Il est dans la nature de l'homme d'opprimer ceux qui cèdent et de respecter ceux qui résistent."

Thu Cydide

Voir aussi :