 |
|
||||
| Spécifier le scénario |
|
lundi 3 janvier, 2011
|
|
||||||||||||||
 |
|||||||||||||||
|
|
|
|||||||||||||
|
|||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||
Lorsqu'une décision stratégique a été prise, il est nécessaire de définir plus avant le scénario retenu en l'affinant davantage.
Spécifiez le scénario :
En quelque sorte, on a fourni un dossier de choix au comité de pilotage suffisamment complet pour permettre un choix cohérent et valable, mais le scénario n'a pas été totalement décrit pour minimiser le temps de l'étude.
La spécification du scénario est donc la description plus précise du scénario retenu afin de pouvoir établir un plan d'action.
Tous les aspects vont être abordés et notamment les aspects organisationnels, fonctionnels, et techniques tout en définissant les modalités d'accompagnement.
La modélisation va jouer son rôle en permettant de mieux formaliser, mieux comprendre et mieux communiquer avec les différents partenaires.
Spécifier un scénario correspond à décrire avec plus ou moins de détail selon le projet, le scénario évoqué.
Un certain nombre d'éléments sont indispensables dans une spécification:
Il faut aussi, rappeler les objectifs, donner des éléments de planification.
Pour les systèmes d'information, il faut décrire plus largement les choses, notamment les aspects fonctionnels et organisationnels, qui sont dans les organisations sociales extrêmement importants.
Exercice N° 28
Spécifiez en détail, le ou les contrôles que vous feriez sur les champs adresse, téléphone et code postal dans une application de gestion de clients.
Compléments :
L'importance de la spécification peut être amplifiée par la nécessité pour le système de ne pas être en défaut. On perçoit assez bien, l'importance des spécifications très formalisées , dans des systèmes d'atterrissage d'avion ou dans des logiciels pouvant en cas de dysfonctionement mettre des vies en péril.
Dans ce cas, il est possible d'établir des spécifications formelles, qui vont permettre de faire la "preuve" que la spécification est "correcte".
Des langages de spécifications formelles existent comme les langages
Z, B, VDM,...
UML n'est pas un langage de spécification formelle, il est souvent qualifié de semi-formel, car il est précis (méta-modèle : modèle du modèle définit sans ambiguité, sans redondance, et assez complet). Ce langage semi-formel est largement suffisant pour la pluparts problèmes de spécification de systèmes d'information qui ne nécessite pas une rigueur aussi strict que les logiciels embarqués sur des avions par exemple.
Exemples : Le cas Bibliothèque.
Spécification d'une règle d'organisation.
R1 :
Si Date_Abonnement < 1 an, Alors statut_abonnement = OK sinon
procédure "Renouvellement_abonnement".
R2 :
Si Nombre_Livres_en_cours_de_prêt < 3, alors statut_nb_prêt = ok
sinon événement "Refusé_Prêt".
R3 :
Si statut_abonnement = OK et statut_nb_prêt = ok Alors
événement "Prêt_livre".
La spécification est nécessaire pour préciser davantage et de manière plus détaillée les éléments du problème.
Une spécification va donc, décrire le système en termes d'information, de traitements sur l'information . Les échanges d'information vont également être décrits. Les aspects organisationnels seront également évoqués.
Pour
réaliser une telle spécification, un certain nombre de méthodes
(Merise, SADT,..) ont proposé des techniques de modélisation
(MOT Merise, Actigramme,..).
Aujourd'hui, la notation UML est une notation universelle permettant de décrire
une telle spécification de manière semi-formelle.
Dans certains cas, la spécification doit être formelle (non ambigüe). Un certain nombre de méthodes de spécification formelle permettent de décrire de manière rigoureuse un système et de vérifier son fonctionnement sans l'avoir obligatoirement implémentée. (VDM, Z, etc..)
Ce type de technique est peu utilisée dans la conception des systèmes d'information..
Dans la plupart des problèmes de systèmes d'information, beaucoup de personnes se contentent d'une spécification textuelle en langage naturel. Nous pensons, qu'il est important de faire un effort de formalisation et d estructuration autour des techniques de formalisation (Modèles, langages de spécification,..)
Spécifier une donnée, c'est définir avec précision l'information en termes de définition
Il est indispensable de préciser les controles que l'on doit impérativement faire sur ces informations.
un autre aspect intéressant est l'évolution de la donnée et les différents états que celle-ci peut prendre. par exemple :
Notre état familial peut passer de Célibataire (statut acquis à la naissance) à marié.
Puis de marié à divorcé ou veuf. De divorcé, nous pouvons de nouveau être marié. etc..
Le modèle conceptuel de données est un excellent outil pour représenter les données à un niveau de détail assez fin.
Il est possible d'ajouter des précisions dans le dictionnaire de données sur le format des données, les contrôles nécessaire sur ces données.
Il est indispensable d'ajouter un modèle de données (Type MCD).
Exercice N° 29 :
Donnez une description détaillée d'un bon de commande de livre.
Compléments :
Les modèles de données permettent une description assez propre des données. Ces descriptions peuvent être stockées dans un "Repository" qui va garder trace de toutes les descriptions de données.
Ces descriptions vont permettre d'éditer des dossiers, mais aussi d'assurer certains contrôles de cohérence ( données-Traitements par exemple).
Une bonne spécification doit s'assurer que chaque donnée est créée, par une procédure, qu'elle est utilisée par au moins une procédure et que sa disparition est prévu par une procédure.
Exemples : Le cas Bibliothèque
Date_Abonnement : C'est la date à laquelle l'étudiant est venu s'inscrire à la bibliothèque. Si cette date est < 1an c'est que l'étudiant est inscrit pour l'année scolaire en cours, il remplit donc les conditions normales pour pouvoir emprunter
Nombre_Livres_en_cours_de_prêt : c'est le nombre de livres que l'étudiant a en prêt à un instant t. Ce nombre obéit à des règles strictes. Il ne peut pas être supérieur à nombre_Livres_Max (Paramètre géré par l'administrateur de la bibliothèque : fixé en début d'année scolaire 2000-2001 égal à 3).
Les traitements doivent être décrits en détail :
Chaque procédure doit être décrite à travers les données qui accompagnent son déclenchement ( Notion d'événement).
Chaque procédure peut être décomposée en tâches (traitements plus fins).
Pour chacune des tâches, il convient d'associer des règles d'organisation.
Dans certaines descriptions, il est possible de :
1 - Donnez une règle de calcul . montant_TTC = Montant_HT * Taux-Taxe
2- Donnez des règles de contrôle de la tâche :
3 - Donnez un verbe d'action pour réaliser une tâche.
Les traitements peuvent se détailler dans une spécification selon deux modes :
Le mode procédural va décrire un traitement comme un ensemble de tâches plus fines. La description de chacune de ces petites tâches donnera une description exhaustive de l'ensemble. Ce mode est appelé procédural, faisant référence à la notion de procédure et de fonction, correspondant au paradigme des années 80-90
Le mode objet peut se faire en utilisant un ensemble de comportement spécialisé dans chacun des objets participants au traitement décomposé. Pour trouver ces comportements, il est possible de s'appuyer sur une séquence de messages que chaque objet impliqué envoie à d'autres objets du système pour les rendre actifs et faire exécuter un de leurs comportements .
Les comportements sont des actions que peuvent exécutées le sobjets. Ainsi, l'objet "Porte" pourra par exemple avoir les comportements : "s'ouvrir", " se fermer".
Exercice N° 30 :
Donnez une description détaillée d'un traitement dans le cas d'un prêt de K7 dans un vidéo-club.
Les règles sont les suivantes :
Pas plus de trois K7 par abonné.
Un abonnement est valable un an.
On ne peut prêter à quelqu'un qui a des retours de K7 en retard quelque soit le nombre.
Compléments :
Les traitements sont également décrits dans le "repository "ou dictionnaire de données. Les traitements sont souvent spécifiés finement à travers un découpage fonctionnelle. Néanmoins, un certain nombre de compléments peuvent être apportés, notamment en décrivant de manière très précise, les données en entrée du traitement (souvent appelées signature), les données en sortie.
Un certain nombre de pré et post-conditions peuvent être précisées :
Les pré-conditions indiquent des conditions qui doivent être vraies pour que les traitements puissent être déclenchés.
Les posts-conditions doivent être vérifiées à la fin du traitement.
Description de l'organisation du système.
L'organisation du système peut être décrit sous forme de traitement. Par exemple, le Modèle Organisationnel de traitement de la méthode MERISE, montre explicitement comment les différents postes de travail vont exécuter leurs tâches pour faire fonctionner le système.
Exemple de MOT
Exemples : Le cas Bibliothèque
L'événement "Refusé_Prêt" est un événement produit par la procédure "demande_de_prêt". Cet événement est produit lorsqu'une des conditions intervenant dans la règle 3 (R3) n'ets pas satisfaite.
Pour une procédure donnée, il est souhaitable de définir, dans quelles conditions, celle-ci peut s'exécuter et quelles sont les conditions qui sont remplies à la fin de la procédure.
De plus une structuration de la logique de la procédure est indispensable.
Les flux correspondent à des échanges entre le monde extérieur et le système (à travers une fonction de celui-ci), ou encore entre deux traitements.
La description des flux est donc de la plus haute importance pour la spécification d'un système d'information ou d'un système logiciel.
En outre cette description va permettre de vérifier une certaine cohérence entre les données et les traitements décrits ci-dessus.
Mais le scénario sera précisé de manière plus fine, en décrivant les flux interne à l'organisation. flux inter-services, inter-postes de travail.
Les flux externes correspondent aux échanges de niveau conceptuel. Les flux internes correspondent aux échanges de niveau organisationnel.
Le diagramme des flux est évidemment un outil intéressant, mais au delà, il est nécessaire de décrire de manière textuelle, les flux en les nommant, en leur donnant un support, en décrivant les données qui les accompagne.
Le flux est également un déclencheur d'action. Il est donc de la plus haute importance d'essayer de comprendre et de spécifier quelle doit être la réaction du système lorsqu'un flux extérieur se produit. Pour les flux internes, il est nécessire de spécifier quelle doit être la réaction d'un poste de travail à l'arrivée d'un flux de ce type.
Le flux est porteur de données. C'est le flux externe qui permet à l'information "fraîche" d'arriver dans le système. L'étude des informations apportées par l'extérieur et la précision de la description de celle-ci sont donc vitale dans une spécification.
Exercice N° 31:
Faites une spécification des flux pour une commande de livre depuis un navigateur internet.
Compléments :
Les flux peuvent être des flux initialisateurs. ils déclenchent le processus et/ou les différentes procédures.
Les flux peuvent permettre à deux traitements d'échanger entre eux.
Nous avons vu l'importance de considérer le flux comme un déclencheur et de lui associer un message. Les flux peuvent être abstraits au niveau classiques de nos préoccupations :
Le niveau conceptuel : le flux sera nommé et l'on pourra lui associer un processus ou une opération du système étudié.
Le niveau organisationnel : le flux sera complété par les informations supportés, le support de l'information (papier, réseau, téléphone, etc..)
Le niveau physique sera également abordé si nécessaire ( Message SMS, Internet,..)
Exemples : Le cas Bibliothèque.
Les flux de la bibliothèque sont assez simples à étudier. Prenons par exemple le nouveau flux " demande de prêt" lié aux échanges inter-bibliothèques universitaires.
il s'agit ici, d'une demande de prêt venant d'une bibliothèque partenaire.
Données nécessaires à ce flux :
Organisationnel
N° livre, Nom bibliothèque demandeuse, date-limite-envoi, adresse_bibliothèque..
Support : lettre ou mail
Physique :
papier ou internet.
Déclencheur
La procédure déclenchée par ce flux est la préparation du prêt. Cette procédure peut être spécifiée d ela manière suivante :
-Vérification de la demande.
- Recherche Livre.
- Préparation du colis.
- Envoi par Collisimo (Délai garanti < 48 heures).
- Enregistrement du prêt.
Décrire une spécification détaillée nécessite d'être organisé et de suivre un plan précis. De nombreuses méthodes proposent des dossiers standards.
Le nom de ces dossiers peut varier d'une méthode à l'autre, mais le contenu reste souvent le même avec ici ou là des différences de plan ou de nom de paragraphe.
Réaliser un dossier n'est pas une simple affaire de documentation. Ce dossier doit être généré tout au long du projet.
Notons que lorsque l'on utilise un atelier de génie logiciel, ce dossier peut être généré automatiquement avec une certaine personnalisation permise par la plupart des outils (Nom spécifique, plan personnalisé, annexes personnalisées).
Exercice N° 32 :
Constituez un mini dossier de spécification d'un traitement d'une commande dans un système de commande via un navigateur.
Compléments :
Dans un dossier, il est possible de compléter un certain nombre de chapitres et de paragraphes descriptifs par des compléments portant sur la gestion de projet :
Ces compléments donnent des indications précises sur l'évaluation du projet en Hommes/jours et donnent également des indications précises sur le délai possible et souhaitable.
EXEMPLE DE Dossier de Specification BIBLIOTHEQUE
Plan :
Les principaux dysfonctionnements de la bibliothèque existante:
Faible fréquentation.
Pas d'accès direct aux livres.
Fermeture du système sur lui-même.
Portillon, code-barre, base documentaire.
Analyse des différents scénarios proposés.
Annexes :
Titre : Le Développement des applications client-serveur Auteur : INMON, W.H. / Editeur : Paris : Masson , 1993 Coll. Méthodes informatiques et pratique des systèmes -
Titre : La Maîtrise pleine et entière de la qualité Auteur : MIZUNO, S. / Editeur : Paris : Economica , 1990
Titre : ISO 9000 : un passeport mondial pour le management de la qualité Auteur : Todorov, Branimir / Editeur : Chicoutimi, PQ : Morin G. , 1994
Titre : Maîtriser la qualité et les coûts des produits et des projets Auteur : DUNAUD, M. / Editeur : Paris : Masson , 1994
