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.
|