Historique des révisions

Date	Version	Description	Auteur
19/10/2001	1.0	Création	ISI3_BE1
13/11/2001	1.1	Limitation des caractéristiques au seul module SNIper	ISI3_BE1

Table des matières

1. Introduction 5

1.1 Objectifs du document 5

1.2 Portée 5

1.3 Définitions, Acronymes et Abréviations 5

1.4 Références 5

1.5 Vue générale et Contenu du Document 5

2. Positionnement 5

2.1 Domaine Métier 5

2.2 Position du problème 5

2.3 Position du produit 6

3. Description des intervenants et des utilisateurs 6

3.1 Population des utilisateurs 6

3.2 Les intervenants 6

3.3 Les utilisateurs 7

3.4 Environnement utilisateur 7

3.5 Profils des intervenants 7

3.5.1 Administrateur système 7

3.6 Profils des utilisateurs 7

3.7 Besoins clés des intervenants / utilisateurs 7

3.8 Alternatives et Compétition 8

4. Vue d’ensemble du Produit 9

4.1 Perspective du produit 9

4.2 Résumé des possibilités 10

4.3 Coût et prix 10

4.4 Installation 10

5. Caractéristiques du produit 10

5.1 Liste des caractéristiques du produit 10

5.1.1 C01 : Création d’un nouveau diagramme SNI 10

5.1.2 C02 : Edition d’un diagramme SNI existant 10

5.1.3 C03 : Sauvegarde d’un diagramme SNI 10

5.1.4 C04 : Exportation / impression d’un diagramme SNI / SEF 10

5.2 Tableau des attributs des caractéristiques 10

6. Contraintes 11

7. Précédence et Priorité 11

8. Autres contraintes sur le produit 11

8.1 Besoins système 11

9. Exigences de Documentation 11

9.1 Manuel Utilisateur 11

9.2 Aide en ligne 12

9.3 Fichier Lisezmoi 12

9.4 Etiquetage et Packaging 12

Document Vision

1. Introduction

GUI Modeler (GUI signifie Graphical User Interface, c’est à dire interface graphique) est un système permettant de concevoir et de réaliser l’Interface Homme Machine (IHM) d’un logiciel. GUI Modeler est basé sur la méthode SNI/SEF de J.B. Crampes.

1.1 Objectifs du document

L’objectif de ce document est de définir les caractéristiques de haut niveau du système GUI Modeler.

1.2 Portée

Le document vision permet d’avoir une vision globale du système du point de vue de l’utilisateur et ne requiert aucune connaissance technique particulière.

1.3 Définitions, Acronymes et Abréviations

Tous les acronymes et abréviations sont définis dans le Glossaire du projet GUI Modeler.

1.4 Références

Les références utilisés pour la réalisation de ce document sont les suivants :

Processus d’ingénierie du logiciel PILPOIL, version adapté du Rational Unified Process (RUP)
« Conception des interfaces graphiques », J.B. Crampes, IUT Blagnac fév. 2001
cours d’UML de l’IUP ISI

1.5 Vue générale et Contenu du Document

La suite de ce document a pour objectif de présenter la collecte, l’analyse et la définition des besoins et de définir les caractéristiques de haut niveau de GUI Modeler qui y répondent.

On définira ici les besoins utilisateurs de tous les modules de l’application GUI Modeler, mais seules seront développées les caractéristiques du ou des modules développés cette année.

2. Positionnement

2.1 D omaine Métier

Le nouveau système offrira aux étudiants et enseignants de l’université un moyen de concevoir plus simplement et plus rapidement des IHM, et mettant en oeuvre la méthode SNI/SEF. Jusqu’à présent, aucun logiciel de conception d’IHM du marché ne supporte cette méthode.

Dans le cadre d’un projet logiciel comportant une IHM, le système offrira un meilleur contrôle du travail réalisé, puisque l’IHM conçue sera également visualisable.

Le nouveau système contribuera aussi à une meilleure compréhension de la méthode SNI/SEF par les étudiants, et peut être à une meilleure diffusion de cette méthode.

2.2 Position du problème

*Le problème de*	la conception d’IHM et la production de maquette.
*Affecte*	tout spécialiste IHM.
*L’impact du problème est*	le temps trop long à produire une maquette car il n’existe pas d’outils spécialisés : le client n’a donc pas de vision rapide de l’IHM et de l’aspect du produit.
*Une solution réussie permettrait*	de simplifier et de raccourcir la phase de conception et de réalisation d’IHM en proposant rapidement une maquette exécutable de l’application. Le retour client n’en sera que meilleur et l’analyse des besoins plus pertinente.

2.3 Position du produit

*Pour*	Les étudiants et les enseignants de l’université
*Qui*	conçoivent et produisent des IHM.
*GUI Modeler*	est une suite logicielle
*Qui*	permet de concevoir et générer facilement des IHM d’après la méthode SNI/SEF
*A la différence de*	la pratique actuelle qui repose essentiellement sur l’utilisation d’éditeurs logiciels non adaptés.
*Notre produit*	permet de modéliser les IHM à l’aide de diagrammes SNI et SEF, et de générer des squelettes de maquettes exécutables comprenant des fenêtres et du code.

3. Description des intervenants et des utilisateurs

3.1 Population des utilisateurs

Tous les étudiants de l’IUP sont amenés dans le cadre de leurs projets de bureaux d’étude à concevoir et réaliser des interfaces hommes-machines. Le produit s’adresse donc tout d’abord à eux, mais aussi aux professeurs d’informatique de l’Université chargés d’enseigner la méthode SNI/SEF et soucieux de pouvoir créer rapidement des exemples d’interfaces, ou souhaitant l’utiliser dans le cadre de leurs recherches.

Le domaine d’application étant assez restreint, ce logiciel n’est susceptible d’intéresser que le département informatique de l’Université. Tous les utilisateurs sont donc habitués à utiliser des applications informatiques.

3.2 Les intervenants

*Nom*	*Représente*	*Rôle*
Superviseur du projet	Représente les deux enseignants encadrant le projet	Joue le rôle de client et suit l’avancement du projet
Analyste	Représente l’équipe d’analystes	Spécifier les besoins et l’architecture de l’application
Développeur	Représente l’équipe de développeurs	Réaliser le projet conformément aux besoins
Administrateur Système	Le CICT / le CRIE	Fournir et gérer les ressources matérielles et logicielles

3.3 Les utilisateurs

*Nom*	*Description*	*Intervenant*
Utilisateur	Personne désirant concevoir une IHM	Représenté par Superviseur du projet

3.4 Environnement utilisateur

La communauté des utilisateurs est située sur le campus de l’UPS. Le logiciel sera en effet donné en libre accès aux étudiants et enseignants sur les machine de l’Université.

Les utilisateurs partagent les mêmes ressources mais aucun système d’échange des données produites n’est prévu entre les utilisateurs.

3.5 Profils des intervenants

Les seuls intervenants sont les personnes impliquées dans le processus de développement, sauf l’administrateur système, tel que définies dans le paragraphe 3.2. Leur profil est actuellement défini dans le processus PILPOIL.

3.5.1 Administrateur système

*Représentant*	Il permet d’accéder aux ressources logicielles et matérielles pour le projet.
*Description*	C.R.I.E.
*Type*	Expert en administration système.
*Responsabilités*	Gestion des ressources matérielles et logicielles.
*Commentaires / Problèmes*	L’administrateur système est sous la direction de l’Université et n’est pas dans l’obligation de réserver les ressources pour la réussite ce projet.

3.6 Profils des utilisateurs

Il n’y a aucun profil d’utilisateur particulier.

3.7 Besoins clés des intervenants / utilisateurs

Echelle des priorités :

· Haute : nécessaire à l’implémentation des autres besoins

· Moyenne : utilise mais pas indispensable

· Faible :

*Désignation*	*Besoin*	*Priorité*	*Concerne*	*Solution actuelle*	*Solutions proposées*
B01	Créer / modifier des diagrammes de type SNI	Haute	Conception de SNI	Manuelle ou à l’aide d’un logiciel graphique non spécialisé	Les SNI sont conçus de manière plus efficace et plus rapide
B02	Créer / modifier des diagrammes de type SEF	Haute	Conception de SEF	Manuelle ou à l’aide d’un logiciel graphique non spécialisé	Les SEF sont conçus de manière plus efficace et plus rapide
B03	Vérifier la cohérence des diagrammes	Faible	Validité des SNI / SEF conçus	Manuelle	Les SNI / SEF respectent les règles imposées par la méthode.
B04	Obtenir une sortie papier des diagrammes, ou les exporter sous une autre forme	Haute	Exploitation des diagrammes produits	Aucune	Une trace du travail est réalisée.
B05	Automatiser la création de SEF à partir d’un SNI	Moyenne	Conception de SEF	Manuelle	Le développement d’un SEF est plus rapide et plus cohérent.
B06	Automatiser la production du code de l’interface à partir d‘un SEF	Moyenne	Développement d’une maquette d’IHM	Aucune	Le développement d’une maquette est plus rapide à partir d’un squelette de code généré
B07	Lancer l’exécution d’une maquette d’IHM	Moyenne	Développement d’une maquette, revue d’IHM	Aucune	Meilleur feedback client, les besoins et les exigences du client sont mieux évalués.
B08	Obtenir de l’aide sur l’utilisation de la méthode	Faible	Documentation de la méthode SNI / SEF	Livre de l’auteur de la méthode, support de cours	La documentation est rapidement accessible car elle est intégrée au sein du produit.

3.8 Alternatives et Compétition

Une maquette d’éditeur SNI/SEF a été réalisée par M. Crampes mais elle a été développée en C++, et il serait trop complexe de porter le code existant vers du Java : elle ne sera donc pas utilisée dans le cadre de ce projet.

Aucun autre logiciel concurrent direct n’est connu à cette période. Seuls des logiciels ou outils bureautiques non appropriés, tels que Microsoft Word© ou Microsoft PowerPoint©, peuvent être utilisés comme alternatives. Cependant, l’utilisation des ces logiciels est fastidieuse.

4. Vue d’ensemble du Produit

4.1 Perspective du produit

Le nouveau système remplacera les outils non appropriés utilisés auparavant.

Ce système comporte plusieurs modules indépendants :

Un éditeur SNI : SNIper

· Un éditeur SEF : SEFcontrol

· Un visualiseur d’interface : GUIViewer

Compte tenu du temps alloué , il est prévu que le développement du système complet (les trois modules) se déroule en trois années consécutives. Bien que ce document décrive les besoins de l’utilisateurs sur les trois modules, seul l’éditeur SNI (SNIper) sera conçu et réalisé cette année.

Il s’agit d’une application mono-poste qui ne nécessite pas l’utilisation du réseau de l’Université.

Les utilisateurs peuvent utiliser l’application sur tous les types de postes disponibles à l’UPS, qu’il s’agisse de Terminaux X ou de PCs.

Aucun système d’authentification n’est prévu dans l’application.

Le système ne communique pas avec d’autres applications.

4.2 Résumé des possibilités

Seules les besoins concernant la manipulation de diagrammes SNI sont couvert ici.

Bénéfice pour le client

Caractéristique réalisant ce bénéfice

Créer / modifier des diagrammes de type SNI

Le logiciel permet la création d’un nouveau diagramme SNI, l’édition d’un diagramme SNI existant, et la sauvegarde des modifications apportées sur un diagramme

Obtenir une sortie papier des diagrammes, ou les exporter sous une autre forme

Le logiciel permet de garder une trace papier du travail produit, ou de générer les

diagrammes dans un autre format exploitable par d’autres applications

4.3 Coût et prix

Le développement et l’installation doivent se faire en utilisant le matériel et les logiciels de l’UPS, et ne doivent donc entraîner aucun coût supplémentaire. Dans le cas où un autre logiciel serait requis, celui-ci doit être libre et gratuit.

4.4 Installation

L’installation devra pouvoir être effectuée sur n’importe quelle machine de l’UPS.

5. Caractéristiques du produit

5.1 Liste des caractéristiques du produit

5.1.1 C01 : Création d’un nouveau diagramme SNI

Le système doit permettre à n’importe quel utilisateur de créer un nouveau diagramme de type SNI. Dès lors, il peut ajouter des éléments à ce diagramme.

5.1.2 C02 : Edition d’un diagramme SNI existant

Le système doit permettre à n’importe quel utilisateur d’éditer un diagramme de type SNI réalisé au préalable grâce au système. Il peut, dès lors, ajouter, supprimer ou modifier des éléments du diagramme.

5.1.3 C03 : Sauvegarde d’un diagramme SNI

Le système doit permettre à n’importe quel utilisateur d’archiver un diagramme SNI sous forme de fichier sur disque. Ce fichier pourra ensuite être édité avec le système.

5.1.4 C04 : Exportation / impression d’un diagramme SNI / SEF

Le système doit permettre à n’importe quel utilisateur de générer une sortie au format papier d’un diagramme SNI ou SEF, ou de l’exporter vers un fichier de format plus standard afin de le rendre utilisable par d’autres applications.

5.2 Tableau des attributs des caractéristiques

Le tableau suivant identifie les principales caractéristiques du système, en termes de bénéfices pour les utilisateurs, et détermine également des ordres de priorités.

Toutes les caractéristiques listées ci-dessous sont essentielles et constituent le but même du logiciel SNIper. Elles devront toutes, en conséquence, être implémentées.

N° *Caractéristique*	*Statut*	*Importance pour l’architecture*	*Effort = estimation charge en jours, heures*	*Affecté à*
C01	Proposé	Basse		Groupe 2^e année
C02	Proposé	Haute		Groupe 2^e année
C03	Proposé	Haute		Groupe 2^e année
C04	Proposé	Haute		Groupe 2^e année

Les caractéristiques C02, C03 et C04 sont importantes pour l’architecture du système dans le sens où elles font intervenir une manipulation de fichiers et impliquent la définition d’une représentation « interne » des diagrammes qui apparaissent à l’écran.

6. Contraintes

L’application doit pouvoir fonctionner sous Unix et sous Windows (l’UPS disposant de machines tournant sous ces deux systèmes).
Il ne doit pas être nécessaire d’avoir lu le manuel pour commencer à utiliser le logiciel.

7. Précédence et Priorité

Toutes les caractéristiques présentes sont à réaliser. Les priorités sont définies sur les cas d’utilisation.

8. Autres contraintes sur le produit

8.1 Besoins système

· Le serveur sur laquelle est exécuté l’application doit disposer d’une console virtuelle JAVA.

· Le développement nécessite une version de Java comprenant des fonctions de dessin de graphes.

9. Exigences de Documentation

9.1 Manuel Utilisateur

Le manuel doit décrire l’usage du système par les utilisateurs. Il doit inclure :

· La configuration nécessaire

· L’installation sur le poste client

· Toutes les fonctionnalités

· Les informations nécessaires au support

9.2 Aide en ligne

Le système doit fournir aux utilisateurs une assistance leur permettant de savoir comment procéder pour utiliser le système.

9.3 Fichier Lisezmoi

Un fichier « lisez moi » doit être proposé à la lecture après l’installation. Il doit pouvoir aussi être lu plus tard. Il inclut :

La liste des erreurs connues et les solutions de contournement.
La liste des nouvelles fonctions de la version courante.

9.4 Etiquetage et Packaging

Le logo de l’IUP ISI et du produit doivent être apparent dans la documentation et les écrans.