Activité :
|
Objet
|
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 |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement des activités : |
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.
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.
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.
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)
|