Référence : CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee

Transcription

1 Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique Etude Détaillée Référence : CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee Date de dernière mise à jour : 13 Mars 2001 Version : 00 Etat : Travail Auteurs : Y. SOLER Diffusion : DSI Objet : Ce document est un guide destiné à l'équipe de spécification (équipe projet DSI) chargé de produire une étude détaillée dans un projet système d'information.

2 Table des mises à jour du document Version du document Date Objet de la mise à jour Mars 2001 Création du document CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

3 Sommaire 1 - OBJET ET DOMAINE D APPLICATION DOCUMENTS DE RÉFÉRENCE ABRÉVIATIONS ET TERMINOLOGIE PRINCIPES D ÉLABORATION ETUDE DÉTAILLÉE DESCRIPTION DES ENCHAÎNEMENTS D'ÉCRANS Formalisme Outil support CONTENU TYPE Etude détaillée ANNEXE : LISTE DE VERIFICATION D'UNE ETUDE DETAILLEE...17 CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

4 1 - OBJET ET DOMAINE D APPLICATION Ce guide donne des recommandations pour produire un dossier d'étude détaillée. Il est destiné à l'équipe de spécification (équipe projet DSI) qui est chargée de produire un dossier d étude détaillée lors de l étape "étude détaillée" dans la phase de développement ou de maintenance/évolution d un système d information. Il présente également des règles de représentation, de description des enchaînements d'écrans d'une application ou d'une évolution et l'outil support proposé (logiciel Visio). Enfin, une liste de questions pouvant aider à relire et vérifier une étude détaillée est fournie en annexe du présent document. 2 - DOCUMENTS DE REFERENCE Plans types : «plan-type-etude-detaillee» «plan-type-enchaînement-écran» 3 - ABREVIATIONS ET TERMINOLOGIE Cf glossaire «Conduite de projet Systèmes d information» 4 - PRINCIPES D ELABORATION Etude détaillée L'étude détaillée vise l'exhaustivité de la description de la solution. Les spécifications détaillées sont la traduction précise des besoins fonctionnels, techniques et organisationnels exprimés par la maîtrise d'ouvrage ou les utilisateurs, en termes de : - traitements à proposer aux utilisateurs de l'application, - données à gérer par l'application, - interface utilisateurs : écrans, états, enchaînement d'écrans, - contraintes de sécurité et techniques. Une fois le dossier d'étude détaillée validé par la maîtrise d'ouvrage, il constitue le cahier des charges pour la production ou la maintenance d'une application. En cas de modifications ou d'évolutions du cahier des charges durant la phase d'élaboration de l'étude détaillée, il est important de veiller à ce qu'il soit maintenu à jour. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

5 4.2 - Description des enchaînements d'écrans Lors de la spécification fonctionnelle de l'interface homme-machine d'une application, il est nécessaire de décrire les écrans (ergonomie de surface) ainsi que les enchaînements d'écrans (dialogue). Ce paragraphe présente le formalisme à utiliser ainsi que l'outil support utilisé (logiciel Visio). Il permet de représenter l'aspect dynamique de l'interface homme-machine en fonction des écrans prévus, des actions possibles de l'utilisateur et des "décisions" prises par l'application. La liste des écrans et des enchaînements d'écran, avec pour chacun une référence et un nom, figure dans le document "étude détaillée" (Cf. contenu type d'une étude détaillée 5.1 du présent document). Exemple : Liste des enchaînements d'écrans : Réf de l'enchaînement d'écran CONC Concours Nom de l'enchaînement d'écran Liste des écrans : Réf de l'écran CONC_1000 CONC_2000 CONC_2100 Nom de l'écran Constitution d'un concours Recherche des concours Consultation d'un concours Dans la suite du paragraphe, on utilisera la terminologie suivante : - action utilisateur : tout événement déclenché par l'utilisateur à l'aide du clavier ou de la souris (clic, sélection, touche clavier...). - action système : tout choix effectué par l'application logicielle en fonction du contexte dans lequel apparaît une action utilisateur (par exemple test d'une liste vide pour savoir si on affiche un écran de liste ou un écran de saisie d'un élément de la liste). Les actions système sont transparentes à l'utilisateur Formalisme Les concepts représentés dans un diagramme d'enchaînement d'écrans sont les suivants : - écran (fenêtre) - actions utilisateur - cliquer sur un bouton d'action - sélectionner un menu et une option de menu - taper sur une touche clavier - actions système. Les conventions d'écriture des noms de ces concepts sont celles utilisées dans les documentations utilisateur des produits DSI. Voir le document : CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

6 Guide méthodologique "Mise en page de la documentation utilisateur des produits" Chaque diagramme contient la référence de l'enchaînement d'écran en conformité avec la liste définie dans le document "étude détaillée". Le diagramme se lit de haut en bas et de gauche à droite selon l'ordre logique de navigation de l'utilisateur. Ecran (fenêtre) L'écran (fenêtre) est représenté par un rectangle arrondi contenant le type d'écran et la référence de l'écran, écrits en texte normal. Les types d'écran possibles sont : - menu : affichage d'un ensemble d'options pour l'utilisateur - liste : affichage d'une liste de données de la base - gestion : affichage de données de la base - utilitaire (palette d'outils...) - dialogue : affichage d'une boîte de dialogue - #à adapter et compléter par projet# Actions utilisateur Les actions utilisateur sont représentées par des noms sur ou à côté des flèches qui relient un écran à un autre. Si plusieurs actions différentes permettent d'obtenir le même écran, il y aura autant de flèches que d'actions. - Cliquer sur un bouton d'action L'action utilisateur de "cliquer sur un bouton d'action" est représentée par le nom du bouton ou de l'icône, écrit entre <signe sup. et signe inf.> Exemple : <Ajouter> Les boutons d'action qui ont une action sur le même écran ne sont pas représentés dans les diagrammes. Par exemple : les boutons <Précédent> et <Suivant> qui permettent de visualiser les informations de la donnée qui précède ou qui suit la donnée affichée parmi une liste de données. Certains boutons "standards" ne sont pas représentés dans les diagrammes car leur comportement est le même quel que soit l'écran où ils apparaissent, par exemple : - Retour : ferme l'écran en cours et retourne à l'écran précédent qu'avait affiché l'utilisateur - Menu : ferme l'écran en cours et retourne à l'écran principal de l'application - Imprimer : affiche l'écran XXX et #à compléter# - #à adapter et compléter par projet# Ces conventions doivent apparaître dans les normes d'ergonomie du projet. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

7 - Sélectionner un menu et une option de menu L'action utilisateur de "sélectionner une option d'un menu" est représentée par le nom du menu et de l'option, en gras italique, séparés par des / sans espace ni avant ni après le /. Exemple : Fichier/Ouvrir - Taper sur une touche clavier L'action utilisateur de "taper sur une touche clavier" est représentée par le nom de la touche respectant la normalisation décrite dans le document : «guide-documentation-utilisateur». Exemple : Ctrl + M, Alt + P, Tab +?, Pomme + P Les raccourcis clavier qui sont équivalents à des clics de boutons ou à des sélections d'option de menus n'ont pas besoin d'être représentés. Ils doivent être décrits dans les normes d'ergonomie du projet. Action système L'action système à effectuer après une action utilisateur est représentée par un ovale contenant l'interrogation qui conditionne le passage à tel ou tel autre écran. Les réponses à l'interrogation (par exemple : oui, non) apparaissent ensuite sur les flèches qui partent de cette action système. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

8 Exemple de formalisme: menu PRINCIPAL Concours/Recherche des concours Existe-t-il au moins un concours? Oui liste Non CONC_2000 <ajouter> <consulter> gestion CONC_2100 CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

9 Outil support Pour réaliser ces enchaînements d'écran, il est recommandé d'utiliser le logiciel Visio. Très simple d'utilisation, il apporte un support au niveau graphique. Pour obtenir le formalisme défini, il suffit de choisir le modèle "enchaînement d'écrans" dans Visio. Pour cela : - ouvrez le logiciel Visio ; - dans la fenêtre qui apparaît, sélectionnez le modèle "enchaînement-écran" qui se trouve dans : 'buzet' > Infos > Bqsd > Conduite-projet > Visio ; CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

10 La palette d'outil dont on dispose ensuite est la suivante : écran action système Action utilisateur Résultat positif à une action système Résultat négatif à une action système Pour créer votre enchaînement d'écran, il suffit de faire glisser la forme désirée dans la page de dessin. 5 - CONTENU TYPE Etude détaillée Ce chapitre présente le contenu que l'on doit trouver dans chaque paragraphe du document "Etude détaillée". 1. DESCRIPTION GENERALE 1.1 Présentation générale de l'application Ce paragraphe a pour but de présenter de manière générale l'ensemble de l'application. Dans le cas d'une étude détaillée pour une évolution : Il s'agit de présenter de manière générale la demande d évolution : ce qu elle doit traiter, l évolution du besoin utilisateur,... et de rappeler les principales fonctionnalités couvertes. Il est également important d'indiquer si le dossier de spécification des évolutions concerne une nouvelle fonction (ou de nouvelles fonctionnalités) du système d information ou si elle modifie une fonction existante. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

11 Pour avoir une meilleure vision de l'évolution, les modules concernés sont regroupés dans un tableau : Nom du module Nouveau module ou ancien module modifié CREATION ou MODIFICATION ou SUPPRESSION CREATION ou MODIFICATION ou SUPPRESSION Exemple : Nom du module GTA 01 FGB 03 HIJ 11 Nouveau module ou ancien module modifié CREATION CREATION SUPPRESSION Dans le cas d une modification, les pages modifiées montreront aussi nettement que possible les évolutions par rapport à la version précédente : utilisation de l'option Révision de Word (marque de révision dans la marge). Lors de la spécification d une modification, le dossier de spécification des évolutions contiendra à minima le descriptif des opérations modifiées, la vue du MLD couvrant ces opérations, les écrans et les états modifiés de ces opérations. Cela veut dire que le dossier de spécification des évolutions ne contiendra pas obligatoirement une description des modules si ceux-ci ne sont pas directement concernés par la modification. 1.2 Description des principales fonctions Ce paragraphe décrit les principales fonctionnalités de l'application. 2. DESCRIPTION DES PRINCIPES D ORGANISATION ET DE GESTION 2.1 Acteurs concernés Identifier ici l'ensemble des acteurs impliqués. Un acteur est une entité organisationnelle identifiable par les missions qu il remplit au sein du champ d étude (acteur interne) ou à l extérieur de celui-ci (acteur externe). Les acteurs sont organisés en postes de travail. 2.2 Principes d organisation et de gestion Décrire les principes d'organisation et de gestion mis en place. 2.3 Description des procédures Une procédure est une suite de tâches exécutées par un ensemble d acteurs et concourant au même but. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

12 Une tâche est un ensemble logique de travaux exécutés par un poste de travail. Une tâche peut être de type temps différé (TD), temps réel (TR) ou manuel (MA). L enchaînement des tâches de la procédure est présenté sous la forme graphique (style MOT). Chaque tâche est décrite par les conditions de son déclenchement, l acteur, les travaux réalisés, les résultats produits, et le temps (durée, fréquence). 3. DESCRIPTION DU MODULE #NOM-MODULE# Un module regroupe un ensemble d'opérations implémentées dans le logiciel. 3.1 Description du Module Historique du module Mentionner les différentes versions du module et décrire pour chacune d'elles les modifications par rapport à l'ancienne version Présentation générale du module Faire une présentation rapide du module Habilitations Définir ici les règles d'habilitations pour le module (droits d'accès, confidentialité ) Liste des opérations Donner dans ce paragraphe la liste des opérations du module en complétant le tableau cidessous. Une opération est un ensemble de traitements automatisés (temps différé ou temps réel) : création, mise à jour, annulation, consultation, édition, calcul... ou manuels. Réf de l'opération Nom de l'opération Type Opération nouvelle ou modifiée CREATION ou MODIFICATION CREATION ou MODIFICATION TR = Temps Réel TD = Temps Différé MA = Manuel Préciser éventuellement si Obligatoire ou Facultatif. Exemple : Réf de l'opération Nom de l'opération Type Opération nouvelle ou modifiée EVAL #nom de l'opération# TR CREATION SASINOM #nom de l'opération# MA MODIFICATION CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

13 3.1.5 Références Entrées/sorties Cette partie a pour but de décrire la liste des enchaînements d'écrans, la liste des écrans ainsi que la liste des états Liste des enchaînements d'écrans Utiliser le tableau ci-dessous pour donner la liste des enchaînements d'écran. Réf de l'enchaînement d'écran Nom de l'enchaînement d'écran Exemple : Réf de l'enchaînement d'écran CONC SELAGT Concours Sélection d'un agent Nom de l'enchaînement d'écran Liste des écrans Utiliser le tableau ci-dessous pour donner la liste des écrans. Réf de l'écran Nom de l'écran Exemple : Réf de l'écran CONC_1000 CONC_2000 CONC_2100 Constitution d'un concours Recherche des concours Consultation d'un concours Nom de l'écran Liste des Etats Utiliser le tableau ci-dessous pour donner la liste des états. Réf de l'état Nom de l'état Exemple : Réf de l'état L002 C001 Nom de l'état Liste des participants au concours Convocation envoyée au candidat CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

14 3.1.6 Orientations techniques et contraintes. Décrire dans ce paragraphe les orientations techniques et les contraintes du module considéré en terme de performance, sécurité Impacts sur la version courante Il s'agit de donner ici la liste des modules à modifier. Décrire les impacts sur la version courante pour chaque opération du module. 3.2 Description de l'opération #nom-opération# Présentation générale Faire un texte introductif présentant d'une manière générale l'opération Références données Tables consultées Tables Mises à jour Exemple : CC6 CNB Tables consultées CDT CTE Tables Mises à jour CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

15 3.2.3 Description des tâches Décrire l'ensemble des tâches effectuées par l'opération considérée à l'aide du tableau cidessous. Réf tâche Type Description Tableattribut Type erreur Code erreur règles de gestion et de calcul Exemple : Réf tâche Type Description Tableattribut 01 S Saisie obligatoire du nom du candidat SCA1 Type erreur Code erreur 15 A Affichage du type de concours CCO2 E Type tâche : A = Affichage C = Contrôle E = Edition M = mise à jour T = Traitement S = Saisie Type erreur : A = Avertissement E = Erreur bloquante Conditions d'exécution Ce paragraphe permet de décrire les conditions d'exécution de l'opération (événements déclencheurs, états de données...) Restriction d habilitation Décrire ici les restrictions par rapport aux acteurs indiqués dans le module Interfaces Préciser dans ce paragraphe s'il existe des interfaces avec d autres modules, d'autres applications ou d autres systèmes d information. 4. DESCRIPTION DES DONNEES Référencer ici le Modèle Relationnel de Données (modèle MRD) de l'application. L'outil de modélisation SILVERRUN doit être utiliser pour réaliser le modèle MRD de l'application. Des recommandations sur l'utilisation du module MRD de SILVERRUN sont disponibles dans le guide méthodologique " Utilisation de SILVERRUN à la DSI ". CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

16 5. ENTREES - SORTIES 5.1 Enchaînements d'écrans Insérer ici le diagramme d'enchaînements d'écrans. Pour réaliser ce diagramme, il est recommandé d'utiliser le logiciel Visio. Un plan type avec le formalisme à respecter est disponible (Cf. plan type "enchaînement-écran").une fois le schéma réalisé sous Visio, utiliser l'option Insertion/Objet /Créer d'après le fichier pour insérer le schéma dans le document Word (cocher la case Lier au fichier afin de pouvoir modifier le schéma ultérieurement en cliquant dessus à partir du document Word). 5.2 Ecrans Les écrans seront présentés sous la forme d une maquette écran. 5.3 Etats Descriptif Maquette Contenu détaillé Décrire dans ce paragraphe les liens entre les champs de la maquette et les données. Champ de la maquette Donnée Table Attribut ou nom de donnée nom table ou calculée indication calculé Champs calculés Il s'agit de décrire ici le mode de calcul, la concaténation de champs, les valeurs forcées, etc Support d impression Préciser ici le support d'impression : écran ou imprimante Algorithme de construction Définir ici : - les critères de sélection des données, - les critères de tri, - les critères de rupture, - la description de l algorithme. CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

17 6 - ANNEXE : LISTE DE VERIFICATION D'UNE ETUDE DETAILLEE La liste ci dessous fournis un ensemble de questions qui peuvent aider à relire des documents d'étude détaillée. ED.1 Exhaustivité O/N ED.1-1 Existe-t-il un document d étude détaillée pour chaque domaine/application ou procédure/module nouveau ou qui a fait l objet d une évolution? ED.1-2 Les documents à mettre à jour qui sont indiqués dans la matrice de traçabilité des demandes de modification sont-ils tous présents? ED.2 Forme O/N ED.2-1 La présentation du document est-elle conforme à la présentation type d un document du projet? en particulier, vérifier : page de garde, entête, pied-de-page, dates du document, référence du document, indices de version d application et de révision du document ED.2-2 Existe-t-il une table des mises à jour et est-elle à jour? ED.2-3 Existe-t-il un sommaire et est-il à jour? ED.2-4 ED.2-5 ED.2-6 ED.2-7 Le plan du document est-il conforme au plan type d étude détaillée d'un projet (voir site web conduite de projet)? Les mises à jour du document par rapport à la révision précédente sont-elles indiquées par des marques de révision dans la marge? N'y a-t-il aucune redondance entre les spécifications de différents paragraphes ou chapitres (par exemple au niveau des contrôles)? N y a-t-il aucun terme ambigu : verbes au conditionnel, «par exemple», «tel que», «à étudier», «éventuellement», «peut-être»...? ED.2-8 Les abréviations utilisées dans le document sont-elles toutes explicitées? ED.2-9 Les spécifications techniques sont-elles restreintes au paragraphe des contraintes (pas de référence à des noms de fichiers ou programmes, à des numéros d enregistrement ou de rubriques dans des fichiers...? Contenu O/N ED.3 Niveau Domaine/application O/N ED.3-1 La présentation générale du domaine/application est-elle complète, non ambiguë, correcte? ED.3-2 La liste des procédures/modules du domaine/application est-elle complète? ED.4 Niveau Contraintes O/N ED.4-1 Les orientations techniques et contraintes sont-elles complètes (temps de réponse, fréquence, précision, mémoire, taille, modularité,...), non ambiguës, correctes? CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

18 ED.4 Niveau Procédure/module O/N ED.4-1 La présentation générale de la procédure/module est-elle complète, non ambiguë, correcte? ED.4-2 La liste des opérations de la procédure/module est-elle complète? ED.4-3 Chaque opération identifiée est-elle non interruptible (pas d attente d événement ou de donnée)? ED.4-4 Le type (manuel, temps différé, temps réel) de chaque opération est-il précisé? ED.4-5 La périodicité (chaque nuit, mensuel...manuel, temps différé, temps réel) de chaque opération est-elle précisée? ED.4-6 L acteur (poste de travail) pour chaque opération est-il précisé? ED.5 Niveau Opération O/N ED.5-1 Les descriptions de chaque opération identifiée sont-elles présentes? ED.5-2 La présentation générale de l opération est-elle complète, non ambiguë, correcte? ED.5-3 ED.5-4 ED.5-5 Les références aux tables de données manipulées et mises à jour par l opération sont-elles complètes? Traçabilité avec les données : les tables de données référencées existent-elles dans le modèle logique de données? Les conditions nécessaires à l exécution de l opération (arrivées d événements, états des données, périodicité...) ainsi que leur combinaison (et, ou,...) sont-elles données? ED.5-6 Les différentes tâches de l opération sont-elles identifiées? ED.5-7 Le type des tâches est-il indiqué et est-il conforme à la codification du projet (voir PACQ)? ED.5-8 La description de chaque tâche est-elle complète, non ambiguë, correcte? ED.5-9 Respecte-t-elle le formalisme prévu? ED.5-10 Est-elle de niveau fonctionnel (non technique)? ED.5-11 ED.5-12 ED.5-13 ED.5-14 Les résultats de chaque tâche (événement, mise à jour de données...) ainsi que leurs conditions d émission sont-ils décrits? Les tables de données sont-elles référencées en conformité avec la liste des tables manipulées par l opération? Les types d action sur les données sont-ils identifiés (création, suppression, mise à jour, consultation)? En cas de modification de règles de gestion, les impacts sur d éventuels compteurs de l application sont-ils précisés? CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19

19 ED.5-15 En cas de modification de règles de gestion, les impacts sur les autres données (en contrôle par exemple) ainsi que les éventuels messages utilisateurs sont-ils précisés? ED.5-16 Les cas d erreur possibles et les messages d avertissement ou d erreur sont-ils identifiés? ED.5-17 Les conditions d affichage des messages sont-elles clairement identifiées? ED.5-18 Les textes des messages sont-ils spécifiés et sont-ils suffisamment explicites pour l'utilisateur (état, cause, solution)? ED.5-19 Y a-t-il homogénéité des messages pour des erreurs de même type? ED.5-20 Le type des erreurs est-il indiqué et est-il conforme à la codification du projet (voir PACQ)? ED.6 Niveau Entrées/sorties O/N ED.6-1 Les diagrammes d enchaînements d écrans sont-ils complets? ED.6-2 Les diagrammes d enchaînement d écrans respectent-ils les conventions d écriture (voir site web conduite de projet)? ED.6-3 Les écrans des diagrammes sont-ils référencés en conformité avec la liste des écrans utilisés? ED.6-4 Les évolutions des diagrammes d enchaînement d écrans sont-elles clairement spécifiées? ED.6-5 La liste des écrans utilisés et des états produits est-elle complète? ED.6-6 ED.6-7 Les écrans et les états sont-ils correctement identifiés (voir les normes de développement du projet)? Les évolutions des écrans et des états sont-elles clairement spécifiées (sur des copies d écrans ou des impressions d états existants ou par maquettage)? ED.6-8 Les écrans et les états respectent-ils les règles d ergonomie du projet? (voir Normes de développement du projet et recommandations ergonomiques de la DSI - document CNRS/DSI/QUAL/METHODE/GuideERGO) ED.6-9 ED.6-10 Pour chaque champ d un écran ou état, trouve-t-on l origine de la donnée (attribut, table) ou la règle de calcul si la donnée est calculée? Les contrôles lors de la saisie de valeurs dans les champs sont-ils définis et font-ils référence aux attributs des tables de l application (directement ou avec des formules de calcul)? ED.6-11 Les contrôles en modification sur des données importées sont-ils décrits? ED.6-12 ED.6-13 Le moment du contrôle est-il précisé : à la saisie d un champ ou à la validation d un écran de saisie? Pour chaque écran ou état contenant des listes, les critères de sélection (quels éléments constituent la liste), de tri (des éléments dans la liste) et de rupture (changement de page) sont-ils spécifiés? ED.6-14 La valeur sélectionnée par défaut dans une liste est-elle précisée? CNRS/DSI/conduite-projet/developpement/technique/guide-etude-detaillee 13 mars / 19