Objet
  • Préparer la sélection de l'ensemble de scénarios et de cas d'utilisation à analyser pour l'itération en cours.
  • Définir un ensemble de scénarios et de cas d'utilisation qui représentent une fonctionnalité importante.
  • Définir un ensemble de scénarios et de 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.
 
Rôle :  Architecte logiciel 
Fréquence : Selon les besoins. Généralement une fois pour chaque itération, à partir de la phase d'élaboration.
Etapes  
Plus d'informations : 
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   

Détails sur l'enchaînement des activités :   

Hiérarchiser les cas d'utilisation et les scénarios Haut de la page

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 qui constitueront la vue des cas d'utilisation 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 chef 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 final, 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.

Ces facteurs doivent être définis en tant qu'attributs des exigences, afin de facilité leur gestion.

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.

Documenter la vue Cas d'utilisation Haut de la page

La vue des cas d'utilisation est décrite dans la section Vue des 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.

 

Evaluer vos résultats Haut de la page

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é. Consultez les points de contrôle applicables à la vue des cas d'utilisation, dans Activité : Revoir l'architecture.



RUP (Rational Unified Process)   2003.06.15