Le but de ce détail de l'enchaînement des activités est de transformer les descriptions comportementales fournies par les exigences dans un ensemble d'éléments sur lequel la conception peut se baser.

Sujets


      Exigence logicielle
Exigence
logicielle
  Carte de navigation
Carte de
navigation
 
         
 
Concepteur d'interface utilisateur
Concepteur
d'interface
utilisateur

 

 
Concevoir l'interface utilisateur
Concevoir
l'interface
utilisateur

 
Effectuer un prototype de l'interface utilisateur
Effectuer
un prototype
de l'interface
utilisateur

 
         
      Carte de navigation
Carte de
navigation
  Prototype d'interface utilisateur
Prototype
d'interface
utilisateur
 

      Classe d'analyse
Classe d'analyse
 
       
 
Architecte logiciel
Architecte
logiciel

 

 
Identifier les éléments de conception
Identifier
les éléments
de conception

 
       
      Sous-système de conception
Sous-système
de conception
Modèle de conception
Modèle de
conception
 
      Paquetage de conception
Paquetage
de conception
Signal
Signal
 
      Evénement
Evénement
Classe de conception
Classe de
conception
 
      Enterprise Java Bean (EJB)
Enterprise
Java Bean
(EJB)
Interface
Interface
 

      Carte de navigation
Carte de
navigation
Modèle de conception
Modèle de
conception
 
       
 
Auditeur technique
Auditeur
technique

 

 
Revoir la conception
Revoir la
conception

 
       
      Compte-rendu de la revue
Compte-rendu
de la revue
 

      Cas d'utilisation
Cas d'utilisation
 
       
 
Concepteur
Concepteur
 

 
Analyse des cas
Analyse
des cas

 
       
      Classe d'analyse
Classe d'analyse
Réalisation de cas d'utilisation de conception
Réalisation
de cas d'utilisation
de conception
 
      Modèle d'analyse
Modèle d'analyse
 


Description Haut de la page

Ce détail de l'enchaînement des activités se produit dans chaque itération dans laquelle les exigences comportementales peuvent être analysées et conçues.

L'analyse des exigences comportementales inclut les éléments suivants :

  • identification des classes d'analyse qui satisfont le comportement requis ;
  • identification du mode d'intégration des classes d'analyse dans l'architecture logique (les principaux sous-systèmes et classes) du système. Les classes d'analyse peuvent être identifiées comme appartenant à des sous-systèmes existants, nécessitant la création de nouveaux sous-systèmes ou entraînant des sous-systèmes existants et leurs interfaces à être redéfinis.

Ce détail d'enchaînement des activités peut également inclure la modélisation et la création d'un prototype de l'interface utilisateur.

Informations connexes To top of page

Cette section fournit des liens vers des informations complémentaires relatives à cet enchaînement des activités.

Calendrier Haut de la page

Commence dans la phase d'élaboration et se reproduit dans les phases de construction et de transition.

Caractère facultatif To top of page

Requis

Dotation en personnel Haut de la page

En particulier dans des projets plus larges, la conception de l'interface utilisateur et la création de son prototype sont effectuées par un groupe distinct de personnes, axées uniquement sur l'utilisabilité du système et de l'interface utilisateur. Cependant, ce groupe doit travailler étroitement avec d'autres membres de l'équipe de développement, en particulier ceux responsables des exigences et de la logique métier, pour s'assurer que l'interface utilisateur correspond à ce que l'utilisateur attend et que la logique métier fournit ce que l'interface utilisateur requiert (en termes de contenu et d'actions utilisateur).

L'Activité : Analyse de cas d'utilisation est mieux réalisée par un petit groupe doté d'un mélange de capacités. Les recommandations en matière de personnel sont présentées dans les Principes et conseils : Atelier d'analyse de cas d'utilisation. L'Activité : Identification des éléments de conception nécessite une perspective plus large de l'architecture et des résultats des autres ateliers d'analyse de cas d'utilisation, et requiert des connaissances sur la technologie d'implémentation et les infrastructures utilisées sur le projet. Les révisions seront menées par des personnes ayant une connaissance approfondie des technologies d'implémentation, ainsi qu'une compréhension du domaine de problème.

Principes et conseils de travail Haut de la page

L'Activité : Conception de l'interface utilisateur et l'Activité : Création d'un prototype de l'interface utilisateur sont réalisées de manière itérative tout au long des itérations de l'élaboration. Les premières itérations se concentrent sur la conception initiale de l'interface utilisateur qui inclut l'identification et la conception des principaux éléments de l'interface utilisateur et les chemins de navigation entre eux. La ../../workguid/wg_stbd.htm -- This hyperlink in not present in this generated websitecréation de scénarimages est une technique efficace qui peut être utilisée lors de la conception d'une interface utilisateur pour mieux appréhender le comportement de l'interface utilisateur. Une fois le consensus sur la conception de l'interface utilisateur initiale atteint, le développement du prototype de l'interface utilisateur exécutable commence. Des commentaires sur le prototype sont renvoyés à la conception de l'interface utilisateur (et si possible aux exigences). Généralement, le prototype initial prend en charge uniquement un sous-ensemble des fonctions du système. Dans les itérations suivantes, le prototype est développé, ajoutant graduellement une couverture plus large des fonctions du système. Le principal avantage de produire des versions non fonctionnelles de l'interface utilisateur est différer l'investissement des prototypes d'interface utilisateur fonctionnels onéreux et plus élaborés jusqu'à ce qu'il y ait un consensus sur la conception globale de l'interface utilisateur. Il est important de travailler étroitement avec les utilisateurs et les utilisateurs potentiels du système lorsque la conception et la création de prototypes de l'interface utilisateur afin de confirmer et de valider l'utilisabilité du système.

Plusieurs ateliers d'analyse de cas d'utilisation peuvent être organisés en parallèle, limités seulement par le pool de ressources disponibles et les capacités des participants. Dès que possible après chaque atelier d'analyse d'étude de cas, certains membres de l'équipe d'architecture travaillent pour fusionner les résultats de l'atelier dans l'Activité : Identification des éléments de conception. Les membres des deux équipes sont essentiels : ceux de l'équipe d'analyse d'étude de cas comprennent le contexte dans lequel les classes d'analyse sont identifiées, tandis que ceux de l'équipe d'architecture comprennent mieux le contexte de conception, ainsi que d'autres cas d'utilisation qui ont déjà été identifiés.

A mesure que le travail de conception mûrit et se stabilise, des parties de plus en plus grandes peuvent et doivent être révisées. Plus petit, davantage de révisions ciblées sont préférables à de grandes révisions générales. Seize révisions de deux heures axées sur des aspects très spécifiques sont largement préférables à une seule révision s'étalant sur deux jours. Dans les révisions ciblées, définissez des objectifs pour lier la cible de la révision et assurez-vous qu'une petite équipe de réviseurs dotés des capacités adéquates, en fonction des objectifs, est disponible pour la révision. Les révisions préliminaires doivent être principalement axées sur l'intégrité des couches et des paquetages de conception, la stabilité et la qualité des interfaces, et la totalité de la couverture du comportement du cas d'utilisation. Les révisions suivantes doivent explorer en profondeur les paquetages et les sous-systèmes pour s'assurer que leurs contenus réalisent complètement et correctement les interfaces définies, ainsi que les dépendances et les associations entre les éléments de conception sont nécessaires, suffisants et corrects. Pour connaître les points de révisions spécifiques, voir les points de contrôle sur chaque artefact de conception.



RUP (Rational Unified Process)   2003.06.15