Analyse des Besoins (Spécifications)

Transcription

1 1 Génie Logiciel (d'après A.-M. Hugues) Analyse des Besoins (Spécifications) Renaud Marlet LaBRI / INRIA màj 17/04/2007

2 Analyse des besoins : 2 Contexte : Position dans le cycle de vie problème posé par le client : cahier des charges Phase d'analyse des besoins : formulation d'une réponse à ce problème (proposition) dossier d'analyse Phase suivante : planification Terminologie alternative : définition du produit, spécification

3 3 Objectifs de ce cours Donner des éléments structurants points clés du dossier d'analyse techniques et outils standards de spécification Intérêt pour celui qui va écrire des spécifications pour celui qui va lire des spécifications techniques réutilisables dans d'autres contextes

4 4 Plan du cours Dossier d'analyse contenu, importance, qualité,... Techniques et outils de spécification modèles, représentations,... Interface utilisateur méthodologie, ergonomie,... Maquettage et prototypage nature, intérêt,...

5 5 Plan du cours Dossier d'analyse contenu, importance, qualité,... Techniques et outils de spécification modèles, représentations,... Interface utilisateur méthodologie, ergonomie,... Maquettage et prototypage nature, intérêt,...

6 6 Contenu du dossier d'analyse (1) Description des fonctions du produit complète et détaillée y compris dans sa relation avec l'environnement Attention : seules sont décrites les fonctions visibles de l'usager pas l'architecture modulaire du produit «boîte noire»

7 7 Contenu du dossier d'analyse (2) spécifications fonctionnelles spécifications non-fonctionnelles première version du glossaire (et dans le cas d'un cycle de vie en V : + tests de validation et de qualification + première version du manuel utilisateur)

8 Cycle de vie : 8 modèle en V (rappel) (Expression des besoins) (Validation des besoins) Spécifications Qualification Conception globale Conception détaillée Tests d'intégration Tests unitaires Programmation

9 9 Importance du dossier d'analyse Erreur dans la spécification coût important si découvert trop tard À la base du contrat protection du client (engagement du fournisseur) protection du fournisseur (attente client bien définie)

10 10 Dossier d'analyse : fait par qui? Généralement réalisé par des membres de l'unité de développement Parfois réalisé par le client attente d'un produit précis Parfois donné par une norme protocole, format d'échange,... exercice : citez des exemples

11 11 Dossier d'analyse : fait pour qui? Pour le client : description précise de ce qui sera réalisé permet d'anticiper la mise en exploitation Pour les développeurs : référence précise et non ambiguë ce qu'il s'agit de réaliser ce qu'il s'agit de tester

12 12 Plan type du dossier d'analyse plan indicatif! (ne pas nécessairement le suivre à la lettre) 1) Introduction objectifs fonctionnalités attendues environnement faisabilité et justifications ressources nécessaires éléments de coût et échéancier

13 13 Plan type du dossier d'analyse 2) Concepts et terminologie glossaire de l'application Peut être en annexe, ou bien un document autonome utilisé et partagé dans tout le projet

14 14 Plan type du dossier d'analyse 3) Description fonctionnelle externe 3.1) Pour chaque «fonction» : ( fonctionnalité abstraite, pas une routine de programme!) entrées (multi-canales) traitement sorties (multi-canales) : effets détails éventuels : conditions d'arrêt exceptions, points de reprise, traitement des anomalies si traitement trop complexe à décrire : algorithme suggéré

15 15 Plan type du dossier d'analyse 3) Description fonctionnelle externe (suite) ) Organisation logique des données types de données domaines de variation 3.3) Interface homme-machine fenêtres et écrans états (représentés ou non) et transitions

16 16 Plan type du dossier d'analyse 4) Description interne 4.1) Interaction avec l'environnement composants logiciels nécessaires aux fonctions en 3.1 (ex. base de données existante) 4.2) Contraintes contraintes de réalisation (ex. encombrement mémoire) contraintes de qualité (ex. précision du calcul) performances critères de vérification des contraintes priorités

17 17 Plan type du dossier d'analyse 5) Questions ouvertes et réponses apportées par les développeurs précisions, faisabilité (éléments de prototypage)... 6) Éléments de livraison cahier provisoire de recette constitution des lots tests de recette dates issues de la planification

18 18 Qualités du dossier d'analyse (1) Précis formulation non ambiguë Cohérent pas de contradictions

19 19 Qualités du dossier d'analyse (2) Complet pas d'oublis couverture de tous les besoins ( cahier des charges) description exhaustive des fonctionnalités Argumenté liaison claire (références) avec des besoins exprimés dans le cahier des charges (des objectifs exprimés dans la spécification d'objectifs) critère de traçabilité ( )

20 20 Qualités du dossier d'analyse (3) Traçable pouvoir suivre le devenir des fonctionnalités dans les phases ultérieures (implémentation, test) Maintenable / flexible comment prendre en compte les évolutions futures?

21 21 Forme du dossier d'analyse Séparation des concepts = 1 concept par paragraphe Numérotation des paragraphes et/ou sections facilité de référence traçabilité (dans les phases ultérieures)

22 22 Plan du cours Dossier d'analyse contenu, importance, qualité,... Techniques et outils de spécification modèles, représentations,... Interface utilisateur méthodologie, ergonomie,... Maquettage et prototypage nature, intérêt,...

23 23 Modèle conceptuel Donne une image «mentale» du produit (!) Recense les fonctionnalités attendues Point de départ à : l'analyse des besoins l'interface utilisateur Extrême importance

24 24 Modèle conceptuel Élaboré à partir des interviews d'utilisateurs Définit, pour chaque grande fonction du produit : les objets (ou entités) que le produit crée/manipule les attributs de ces objets les opérations à réaliser sur ces objets

25 Exercice : 25 Définir un modèle conceptuel Messagerie téléphonique du type SMS / texto : consulter les messages dans la boîte de réception supprimer un message envoyer un message faire suivre ou répondre à un message consulter les contacts dans le répertoire ajouter et supprimer des contacts dans le répertoire Quels sont les objets et les relations (notamment de possession) entre objets?

26 Objets et relations dans une 26 messagerie textuelle téléphonique Objets boîte de réception message (2 types : reçu, en cours de rédaction) répertoire contact Relations la boîte de réception contient une liste de messages un message provient de / est destiné à un numéro un contact a un nom et un numéro

27 Modèle conceptuel de la messagerie 27 Exercice : remplir le tableau Grand type de fonction du produit Objet (et attributs) Liste des opérations Exemple de contraintes éventuelles gestion de la boîte de réception gestion d'un message reçu création d'un nouveau message gestion du répertoire gestion d'un contact

28 Exemple de modèle conceptuel 28 de la messagerie Grand type de fonction du produit Objet (et attributs) Liste des opérations Exemples de contraintes éventuelles gestion de la boîte de réception boîte de réception (liste de messages reçus) consulter la liste, sélectionner un msg nombre maximum de messages gestion d'un message reçu message reçu (suite de caractères non modifiable) lire, faire suivre, répondre, supprimer création d'un nouveau message message en cours (suite de caractères) éditer, envoyer, annuler taille maximum d'un message gestion du répertoire répertoire (liste de contacts) consulter la liste, ajouter un contact, sélectionner un contact nombre maximum de contacts gestion d'un contact contact (nom, numéro) modifier, supprimer taille maximum du nom, du numéro

29 29 Choix dans le modèle conceptuel Ajout et de suppression de message opération sur un message sur la boîte de réception? Ajout et suppression de contact opération sur un contact ou sur le répertoire? Plus généralement, il y a un choix quand une opération relie deux objets en particulier : un contenant avec un contenu

30 30 Importance du modèle conceptuel Il structure identification de concepts, objets, attributs, opérations et de leur articulation Il fonde l'intuition image mentale : analogie avec des concepts, objets, attributs et opérations connus apprentissage réduit Il facilite l'interaction efficacité, productivité

31 31 Importance du modèle conceptuel Impact sur tout les acteurs utilisateur développeur (projet complexe) décideur

32 Différents types de 32 modèles conceptuels Modèle de simulation lien avec un existant concret Modèle structurel abstraction On va en donner des exemples

33 Modèle conceptuel de simulation 33 Exemple : traitement de texte Recréer une technologie connue Machine à écrire, papier page = zone rectangulaire contenant des cellules (caractères ou blancs) [regroupées en lignes] un curseur (là où le prochain caractère s'imprime) actions surimpression d'un caractère où se trouve le curseur (d'après P. Baudelaire) écrire, effacer (blancs), copier des caractères [sur une ligne]

34 Modèle conceptuel structurel 34 Exemple : traitement de texte Manipulation et représentation d'entités abstraites Document = chaîne de caractères arbitrairement longue, organisée hiérarchiquement en sections, paragraphes, mots... manipulations à travers cette structure logique insérer, détruire, remplacer, déplacer, copier pas de limitation à des opérations sur une seule ligne spécification et enregistrement de règles de formatage changer le style sans changer le contenu (d'après P. Baudelaire)

35 Comparaison des différents types 35 de modèles conceptuels Modèle de simulation avantage : intuition facile inconvénient : peut être limitatif Modèle structurel avantage : plus général, plus puissant inconvénient : peut demander un plus grand travail de conceptualisation

36 36 Dictionnaire de données Souvent amorcé par le modèle conceptuel Constitué au fur et à mesure de l'analyse Nom de tous les objets utilisés (+ attributs, opérations,...) classement alphabétique (+ synonymes ou alias) lien avec de futures entités issues du développement variables, fonctions, classes,...

37 Modèle conceptuel et 37 besoins de spécification Descriptions avec des mots concepts, objets, attributs, opérations... Besoin de structuration pour la précision pour la complétude (comment être systématique?) pour la lisibilité Représentations tabulaires

38 38 Table de décision Définition des valeurs de sorties en fonctions des valeurs d'entrée et de leurs combinaisons Adapté aux systèmes dont les sorties ne dépendent que des entrées (et pas de l'état courant)

39 Exemple : 39 «date et heure» de MAC OS X

40 Table de décision : Exemple 40 «date et heure» de MAC OS X Affichage du jour de la semaine (lundi, mardi,...) : Paramètres d'entrée : «Afficher dans» : [barre des menus] ou [fenêtre] «Affichage» : [numérique] ou [analogique] Paramètre de sortie : «Afficher le jour de la semaine» : oui, non, optionnel Afficher le jour de la semaine Afficher dans : barre des menus Affichage : numérique optionnel Affichage : analogique non Afficher dans : fenêtre oui non

41 Table de décision : Exemple 41 «date et heure» de MAC OS X Affichage de l'heure avec les secondes Paramètres d'entrée : «Afficher dans» : [barre des menus] ou [fenêtre] «Affichage» : [numérique] ou [analogique] Paramètre de sortie : «Afficher l'heure avec les secondes» : oui, non, optionnel Afficher l'heure avec les secondes Affichage : numérique Affichage : analogique Afficher dans : barre des menus optionnel non Afficher dans : fenêtre non optionnel

42 42 Question Quelle structure de table s'il y a plusieurs paramètres de sortie?

43 43 Réponses possibles Quelle structure de table s'il y a plusieurs paramètres de sortie? Autant de tables que de paramètres de sortie ( ) Liste des sorties dans chaque case ( )

44 Table de décision : Exemple 44 «date et heure» de MAC OS X Affichage du jour de la semaine et des secondes : Paramètres de sortie : «Afficher le jour de la semaine» : oui, non, optionnel «Afficher l'heure avec les secondes» : oui, non, optionnel Afficher le jour et/ou les secondes Afficher dans : barre des menus Afficher dans : fenêtre Affichage : numérique jour optionnel secondes optionnelles jour présent secondes absentes Affichage : analogique jour absent secondes absentes jour absent secondes optionnelles

45 45 Question Quelle structure de table s'il y a plus de deux paramètres d'entrée?

46 46 Réponse possible Quelle structure de table s'il y a plus de deux paramètres d'entrée? Combinatoire autant de colonnes que de paramètres d'entrée et toutes les combinaisons possibles

47 47 Table de décision : Exemple (1) 3 paramètres d'entrée (booléens) 1 paramètre de sortie (booléen) A B C (A B) C V V V V V V F V V F V V V F F F F V V V F V F F F F V V F F F F N.B. pas de titre pour les lignes

48 48 Table de décision : Exemple (2) 3 paramètres d'entrée (booléens), 1 de sortie (booléen) résultats intermédiaires pour la compréhension A B C A B (A B) C V V V V V V V F V V V F V F V V F F F F F V V F V F V F F F F F V F V F F F F F N.B. pas de titre pour les lignes

49 49 Question Quelle structure de table s'il y a plusieurs paramètres d'entrée et plusieurs paramètres de sortie?

50 50 Réponse possible Quelle structure de table s'il y a plusieurs paramètres d'entrée et plusieurs paramètres de sortie? Combinatoire autant de colonnes que de paramètres d'entrée et de paramètres de sortie et toutes les combinaisons possibles

51 Table de décision : Exemple 51 «date et heure» de MAC OS X Deux paramètres d'entrée : «afficher dans», «affichage» Deux paramètres de sortie : jour de la semaine, heure avec les secondes Afficher dans Affichage Jour de la semaine Secondes barre des menus numérique optionnel optionnel barre des menus analogique non non fenêtre numérique oui non fenêtre analogique non optionnel

52 Capacité de représentation d'une 52 table de décision Exprimer une fonction = sorties définies en fonction des entrées Exprimer une relation = quelles combinaisons d'entrées et de sorties sont acceptables peu courant non-déterminisme confusions / oublis possibles

53 Table de décision et 53 besoins de spécification (1) Table de décision : sorties en fonction (ou en relation avec) des entrées Limites : besoin de modéliser l'état du système des relations entrées-sorties dépendant de l'état des relations entrées-sorties modifiant l'état Comment faire?

54 Table de décision et 54 besoins de spécification (2) Besoin de modéliser l'état du système traiter l'état comme un paramètre ordinaire des relations entrées-sorties dépendant de l'état état comme paramètre d'entrée supplémentaire des relations entrées-sorties modifiant l'état état comme paramètre de sortie supplémentaire Table de transition

55 55 Table de transition Automate modélisant la dynamique du système Adapté aux systèmes dont les sorties sont déterminées non seulement par les entrées mais aussi par l'état/historique des entrées antérieures

56 Table de transition : Exemple 56 autorisation d'accès par login 2 états : logué, délogué 4 opérations : se loguer, se déloguer, lire, écrire État Opérations autorisées État résultant délogué se loguer logué logué lire, écrire logué logué se déloguer délogué

57 57 Question Structures de table : Quels cas sont bien traités? Quels cas ne sont pas bien traités?

58 Tables (de décision, de transition) et 58 besoins de spécification Bien adaptées tant que le problème est petit Ne passent pas à l'échelle (s'il y a un grand nombre de paramètres d'entrée, de sortie ou d'états) croissance exponentielle mauvaise lisibilité risque d'erreurs (oublis, incohérences,...) Comment faire?

59 59 Représentations graphiques Pouvoir d'expression : représentation des données et des traitements Caractéristiques : plus synthétiques que les tables sans nécessairement perte de précision

60 60 Représentations graphiques Pas un dessin arbitraire! en fait, «langage» normalisé sémantique non ambiguë (ou peu ambiguë, si accompagnées de textes en langue naturelle) Représentations «semi-formelles»

61 Intérêt des 61 représentations graphiques Renforcement de la précision et de la lisibilité Réduction du risque d'oubli ( systématique) Passage à l'échelle (éventuellement en rajoutant de la modularité) Plus intuitives bien que plus formelles favorisent la communication entre le développeur et l'utilisateur (le client)

62 62 Représentations graphiques Modèle entité-association Diagramme de flot de données Diagramme états-transitions Réseau de Petri...

63 63 Modèle entité-association Date de 1976 (P. Chen) mais toujours très utilisé Représentation des données d'un système et des relations les liant (Utilisé notamment pour la conception de bases de données relationnelles, mais avec des contraintes supplémentaires, ex. non circularité)

64 64 Modèle entité-association Une entité est un objet que l'on sait distinguer d'un autre ex. : livre dans une bibliothèque Chaque entité a des attributs (ou propriétés) ex. : titre, nom, numéro,... Chaque attribut prend ses valeurs sur un domaine de valeurs autorisées ex. : chaîne de caractères, entier de 1 à 31,...

65 65 Modèle entité-association Les entités peuvent être regroupées en des ensembles d'entités ayant les mêmes attributs avec des valeurs différentes ex. : livres d'une bibliothèque, clients d'une entreprise Une clé ou un identifiant permet de distinguer une entité (ou un ensemble d'entités) d'un(e) autre ex. : titre d'un livre, ou numéro de référence si plusieurs exemplaires du même livre

66 66 Modèle entité-association Une relation entre différentes entités ou ensemble d'entités est un lien d'association entre eux (possession, dépendance,...) ex. : un livre possède un auteur, un client d'une banque possède un ou des comptes en banque La cardinalité d'une relation est le nombre de liens (minimum, maximum) pour un ensemble d'entités

67 Modèle entité-association : 67 Notations graphiques Entités représentées par des rectangles Attributs attachés aux entités : liste d'attributs Identifiant de l'entité : item souligné dans la liste Relations : ovales Cardinalités : (x,y) c.-à-d. entre x et y adhérent emprunte (0,n) emprunter est empruntée (0,1) cassette N exemplaire date d'achat nb emprunts état

68 Modèle entité-association 68 Exemple : vidéothèque numéro nom caution nb films adhérent carte possède (1,1) posséder emprunte (0,n) est possédée (1,1) réserve (0,n) date emprunter réserver fournisseur est empruntée (0,1) est réservé (0,n) cassette reproduire film reproduit (1,1) N exemplaire date d'achat nb emprunts état est reproduit par (0,n) numéro ref fournisseur nom fournisseur adresse fournisseur téléphone fournisseur responsable commercial fournit (1,n) fournir prix est fourni (1,n) code film titre réalisateur acteurs genre résumé

69 Modèle entité-association et 69 besoins de spécification Relations états statiques possibles Ne rend pas compte de la dynamique des traitements du flux d'information Diagrammes de flot de données

70 70 Diagramme de flot de données Modélise les gisements d'information le transit des données les traitements Exprime comment chaque processus (traitement) transforme ses entrées en sorties (flot entrant et sortant) (aussi appelé «diagramme de contexte» = idem avec agents extérieurs intervenant sur le produit)

71 Diagramme de flot de données 71 Exemple : gestion des emprunts refus carte infos film demande d'emprunt référence film vérification cassette vérification client comptes clients N carte refus stock de cassettes N client N cassette enregistrement emprunt carte modifiée cassette

72 72 Diagramme de flot de données Affinements successifs : zoom sur une boîte numérotation arborescente (ex. : A.D.3) veiller à la cohérence des entrées et sorties

73 73 Diagramme de flot de données Conseils : ( ) Entre 2 et 6 activités par diagramme (sinon découper) Flot globalement de gauche à droite, de bas en haut Éviter les croisements de flèches

74 Diagrammes de flot de données et 74 besoins de spécification Ne conviennent pas pour le flot de contrôle ce ne sont pas des organigrammes! Ne rendent pas compte de la dynamique des traitements l'enchaînement des traitements dans le temps Diagrammes états-transitions

75 75 Diagramme états-transitions Graphe : nœud = état arête = transition, étiquetée par les événements qui provoquent la transition ou les événements provoqués par la transition Représentation ordinaire des automates finis

76 Diagramme états-transitions : 76 Ex. Cassette dans une vidéothèque Cassette commandée Demande d'emprunt et réponse N de cassette Cassette disponible Livraison de la cassette et enregistrement de l'entrée de la cassette Demande d'emprunt et réponse de refus Cassette empruntée Emprunt de la cassette et enregistrement de l'emprunt Retour cassette et enregistrement du retour Cassette perdue Temps d'emprunt dépassé et enregistrement de la perte de la cassette

77 77 Diagrammes états-transitions Rendent compte de : la dynamique des traitements l'enchaînement des traitements dans le temps Exemples d'application comportement d'un objet réactif enchaînements d'écrans avec IHM complexes

78 Comparaison : Table de transition et 78 Diagramme états-transitions État Opérations autorisées État résultant délogué se loguer logué logué lire, écrire logué logué se déloguer délogué délogué se loguer se déloguer lire, écrire logué

79 79 Non-déterminisme (1) Plusieurs transitions avec la même étiquette, partant d'un même état Transition : sans événement attaché Ex. transitions de l'état 1 à l'état 2 = {acd, a, b, f, aef} a 1 a c b e d 2 f

80 80 Non-déterminisme (2) Automate déterministe plus lisible (une seule transition à suivre) moins compact si le problème comporte de l'indéterminisme (peut être exponentiellement plus grand) Automate non déterministe moins lisible (suivre des transitions en parallèle) plus compact (donc plus lisible )

81 Diagramme états-transitions et 81 besoins de spécification Ne permettent pas d'exprimer la «concurrence» (= parallélisme) Réseaux de Petri

82 82 Réseau de Petri Graphe biparti sommets répartis en 2 groupes chaque arête a une extrémité dans un groupe et une extrémité dans l'autre groupe Sommets (nœuds) place entrée (pré-condition) place entrée (pré-condition) place état transition marques (jetons) dans certaines places, à un instant donné place sortie (post-condition) transition changement d'état

83 83 Réseau de Petri Déclenchement d'une transition : présence de jetons dans toutes les places entrée décrémentation du nb de marques des places entrée incrémentation du nb de marques des places sortie non-déterministe, atomique

84 Réseau de Petri : Exemple 84 Délivrance d'une cassette P1 T1 P2 P3 T2 T3 T4 T5 P1 : emprunt demandé P2 : vérification de la cassette P3 : vérification de l'adhérent P4 : emprunt refusé P5 : emprunt possible P6 : emprunt possible P7 : emprunt refusé P8 : emprunt autorisé P4 P5 T6 P6 P7 T1 : préparation de la vérification (action) T2 : cassette empruntée (condition) T3 : cassette disponible (condition) T4 : adhérent en règle (condition) T5 : adhérent pas en règle (condition) T6 : autoriser l'emprunt (action) P8 emprunt autorisé si cassette disponible et adhérent en règle

85 85 Réseau de Petri Ordonnancement des activités Modélisation systèmes parallèles à événements discrets concurrence, coopération ex. exclusion mutuelle, producteur/consommateur Extensions marques colorées, arcs inhibiteurs, limites de taille, transitions sources, transitions puits,... Variante (dual) : Grafcet

86 86 Méthodes semi-formelles Répandues dans l'industrie Nombreux outils qui les implémentent Inconvénient : manque (parfois) de rigueur mathématique Méthodes formelles

87 Méthodes d'analyse formelles : 87 Caractéristiques Spécifications formelles = objets mathématiques modélisations analysables par les mathématiques Nécessité d'une analyse profonde du problème meilleure maîtrise Preuves formelles (mathématiques) certaines propriétés garanties (sûreté, sécurité,...) ex. correction : programme conforme à sa spécification

88 Méthodes d'analyse formelles : 88 Capacités automatiques Aide au développement debug de spécification (vérification de cohérence) génération (semi-)automatique de code génération (semi-)automatique de tests Animation d'une spécification ~ génération de prototype

89 Méthodes d'analyse formelles : 89 Problèmes objectifs Certains problèmes difficilement spécifiables interface homme-machine, système temps-réel,... Manque de formation ingénieurs logiciel mathématiciens, logiciens Efforts plus sur les notations que sur les outils preuves faisables mais difficiles à réaliser en pratique

90 Méthodes d'analyse formelles : 90 Croyances Croyances (conservatrices) du management rentabilité pas prouvée en fait : souvent plus cher mais de meilleure qualité Croyance (frileuse) des développeurs : peu de problèmes spécifiables formellement en fait : gros systèmes déjà spécifiés (gestion de fichiers Unix, JavaCard, systèmes de transport,...) Croyance (naïve) des chercheurs : problèmes de développement résolus dès qu'on adopte des méthodes formelles

91 Méthodes d'analyse formelles : 91 Quelques formalismes Spécifications opérationnelles (= enchaînement des actions) automates, systèmes de transition, logique de Hoare langages : VDM, Z, B,... Spécifications axiomatiques (= propriétés que doivent satisfaire les implémentations) spécifications algébriques : OBJ, Larch,...

92 Méthodes d'analyse formelles : 92 La situation aujourd'hui Peu répandues utilisées pour des systèmes critiques (sécurité) Mais représentent l'avenir de la spécification mais avenir lointain Besoin d'outils plus simples (moins d'expertise nécessaire) plus puissants (moins de choses à expliciter)

93 93 Et aussi... Critères Communs (CC)... sécurité

94 Récapitulatif des 94 Techniques et outils de spécification Modèle conceptuel Représentations tabulaires : table de décision table de transition Représentations graphiques semi-formelles : modèle entité-association diagramme de flot de données diagramme états-transitions réseau de Petri,... Méthodes formelles

95 95 Plan du cours Dossier d'analyse contenu, importance, qualité,... Techniques et outils de spécification modèles, représentations,... Interface utilisateur méthodologie, ergonomie,... Maquettage et prototypage nature, intérêt,...

96 96 Interface utilisateur Souvent objet de concurrence entre applications (peu de différences «sous le capot») Reflet des fonctionnalités du produit [ Terminologie : français : interface homme-machine (IHM), interface graphique anglais : graphical user interface (GUI) ]

97 Spécification de 97 l'interface utilisateur Tôt dans le cycle de vie spécifications fonctionnelles Nombreuses discussions avec l'utilisateur/client maquette pour valider l'interface (~ seul moyen efficace d'une discussion profitable)

98 98 Interface utilisateur : Méthodologie Partir du modèle conceptuel des données et traitements Définir un modèle conceptuel du dialogue représentation de l'information interactions Choix crucial d'un bon modèle conceptuel

99 99 Interface utilisateur : Ergonomie (1) Convivialité facilité d'utilisation mesure : ex. nombre de jours d'apprentissage Efficacité productivité des utilisateurs ( mesure) caractériser les types d'utilisateurs ciblés compétence but du travail performances attendues,...

100 100 Interface utilisateur : Ergonomie (2) Lisibilité mise en avant des données pertinentes/prioritaires regroupement des données similaires alignement visuel des données sens/ordre de lecture «ordinaire» stabilité d'un écran à l'autre Standardisation marché, influence du système d'exploitation/fenêtrage normes de l'entreprise conventions liées au domaine

101 101 Interface utilisateur : Outils (1) Utilisation de «briques de base» standards fenêtres, boîtes de dialogue, onglets menus : fixes, déroulants, pop-up boutons, jauges choix : cases à cocher, boutons radio, vidéo inverse raccourcis clavier aides visuelles : icônes, couleurs effets visuels : images, animations...

102 102 Interface utilisateur : Outils (2) Utilisation de bibliothèques standards X Athena Widget Motif Tk Swing GTK, GTK+ OpenGL...

103 103 Plan du cours Dossier d'analyse contenu, importance, qualité,... Techniques et outils de spécification modèles, représentations,... Interface utilisateur méthodologie, ergonomie,... Maquettage et prototypage objectifs, nature, intérêt,...

104 104 Maquettage et prototypage Quand : après le premier jet des spécifications fonctionnelles Objectifs : montrer au client à quoi ressemblera le produit valider les besoins et les spécifications

105 105 Maquette Système incomplet dont l'aspect extérieur est +/- le même que le produit à réaliser Destiné à tester l'ergonomie du produit Instaure un dialogue développeur-utilisateur Ne permet pas le test de performance Souvent jetable

106 106 Prototype Esquisser ce que sera le produit final les fonctionnalités sans contraintes (fiabilité,...) Valider les besoins utilisateur réalisables? Valider les spécifications complètes, réalistes, non contradictoires? Souvent jetable (sinon = prototype évolutif)

107 107 Prototype Intérêt évaluer rapidement la faisabilité, mais aussi : mettre en évidence les incompréhensions développeur-utilisateur identifier les services difficiles à utiliser découvrir les contradictions détecter les oublis de spécification servir de base à l'écriture de spécifications complètes

108 108 Prototype Ignorer les critères non-fonctionnels : temps de réponse, contraintes mémoire traitements d'erreur standards fiabilité, robustesse... (sauf si la faisabilité en dépend!)

109 109 Prototype Choix d'un langage de prototypage adapté impératif : perl, shell, java,... fonctionnel : ML, lisp, scheme,... déclaratif : prolog,... spécifique à un domaine ex. programmation réactive : ESTEREL, SIGNAL, LUSTRE ex. modélisation de processus : SIMULA, QNAP2

110 110 Prototyper n'est pas spécifier Un prototype ne remplace pas des spécifications il ignore les critères non fonctionnels il ne peut être une base fiable du contrat (à la différence du dossier d'analyse)

111 111 Du prototype à l'implémentation Ré-implémentation toujours recommandable Mais difficulté à intégrer des contraintes non fonctionnelles dégradation de la structure après prises en compte successives des demandes de l'utilisateur réutilisation possible de certains composants du prototype réimplémentation plus rapide grâce à une bonne connaissance du problème