Tâche: Hiérarchiser les cas d'utilisation
Cette tâche consiste à hiérarchiser les cas d'utilisation, de manière à ce que leur ordre de développement puisse être établi. Cette tâche consiste à identifier et à hiérarchiser les cas d'utilisation importants sur le plan de l'architecture.
Disciplines: Exigences
Objet

L'objectif de cette tâche est de :

  • Préparer la sélection de l'ensemble des scénarios et des cas d'utilisation à analyser pour l'itération en cours.
  • Définir l'ensemble des scénarios et des cas d'utilisation qui représentent une fonctionnalité centrale.
  • Définir l'ensemble des scénarios et des cas d'utilisation qui présentent une couverture architecturale importante (qui concernent de nombreux éléments de l'architecture) ou qui illustrent un point spécifique particulièrement délicat de l'architecture.
 
Relations
Description principale

Certains des facteurs utilisés pour déterminer la priorité des cas d'utilisation peuvent être enregistrés en tant qu'attributs d'exigence logicielle.Ces priorités peuvent aussi être enregistrées comme des attributs d'exigence afin de faciliter leur gestion.

Pour plus d'informations sur les attributs d'exigence, voir aussi Instructions : Plan de gestion des exigences.

Etapes
Hiérarchisation des cas d'utilisation et des scénarios

Un architecte logiciel propose le contenu technique et l'ordre des itérations successives en sélectionnant un certain nombre de scénarios et de cas d'utilisation à analyser et à concevoir. Cette proposition technique est ensuite complétée et affinée par les différentes équipes de développement, en fonction des disponibilités de chacun, des exigences du client en termes de livrables, de la disponibilité des outils et des produits COTS, et des besoins des autres projets.

Le choix des scénarios et des cas d'utilisation considérés comme étant importants du point de vue de l'architecture (comme, par exemple, ceux qui constitueront la vue de cas d'utilisation de l'architecture) est guidé par un certain nombre de facteurs clés, énumérés ci-dessous. 

  • Importance du scénario pour les parties prenantes : essentiel, important, utile.
  • Impact du scénario sur l'architecture : aucun, extension, modification. Certains cas d'utilisation essentiels peuvent avoir un impact minime sur l'architecture, alors que des cas d'utilisation apportant peu d'avantages peuvent avoir un impact très important. Dans cette deuxième hypothèse, le responsable de projet doit revoir le cas d'utilisation pour en redéfinir la portée.
  • Risques à limiter (performance, disponibilité d'un produit et adéquation d'un composant).
  • Exhaustivité de la couverture architecturale (il s'agit de s'assurer qu'à la fin de la phase d'élaboration, chaque composant logiciel à développer ait trouvé sa place dans la vue d'implémentation).
  • Autres contraintes ou objectifs tactiques : démonstration pour l'utilisateur, etc.

Deux scénarios peuvent concerner les mêmes composants et répondre à des risques similaires. Si vous implémentez d'abord A, alors B n'est pas important du point de vue de l'architecture. Si vous implémentez d'abord B, alors A n'est pas important du point de vue de l'architecture. Les attributs peuvent donc dépendre de l'ordre d'itération et doivent être réévalués si l'ordre change, et également si les exigences elles-mêmes changent.

Les cas d'utilisation qui sont importants architecturalement mais mal compris ou susceptibles d'évoluer, doivent être hiérarchisés pour clarification et stabilisation. Dans certains cas, cela signifie qu'il convient d'analyser les exigences de manière plus approfondie avant de procéder à l'implémentation. Dans certains autres cas, il peut être préférable de créer des prototypes.

Documentation de la vue de cas d'utilisation

La vue de cas d'utilisation est documentée dans la section vue de cas d'utilisation du document architecture logicielle. Cette section contient une liste des principaux cas d'utilisation et scénarios pour chaque package du modèle de cas d'utilisation, ainsi que les propriétés significatives, comme le flux d'événements, les relations, les diagrammes de cas d'utilisation et les exigences spéciales liées à chaque cas d'utilisation. Si la vue des cas d'utilisation est développée de manière précoce dans l'itération, il est possible que certaines de ces propriétés ne soient pas encore présentes.

Evaluation de vos résultats

Vous devez évaluer la vue des cas d'utilisation à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Pour obtenir des recommandations sur les éléments à rechercher pendant la revue, voir aussi Liste de contrôle : Document d'architecture logicielle.

Plus d'informations