Détail de l'enchaînement des activités : Précision de l'architecture
L'objectif de
cet enchaînement des activités est de compléter l'architecture d'une
itération. |
Rubriques
|
|
Détail de l'enchaînement des activités
- Procure la transition naturelle des activités d'analyse aux
activités de conception, identifiant :
- les éléments de conception appropriés à partir des éléments
d'analyse,
- les mécanismes de conception appropriés à partir des mécanismes
d'analyse connexes.
- Décrit l'organisation de l'architecture de déploiement et
d'exécution du système.
- Organise le modèle d'implémentation de façon à faire la transition
transparente entre la conception et l'implémentation.
- Gère la cohérence et l'intégrité de l'architecture, assurant
que :
- de nouveaux éléments de conception identifiés pour l'itération
courante sont intégrés avec des éléments de conception pré-existants ;
- une réutilisation maximale des composants disponibles et des éléments
de conception est effectuée dès que possible dans l'effort de conception.
Cette section fournit des liens vers des informations complémentaires
relatives à cet enchaînement des activités.
Commence dans la phase d'élaboration et se reproduit dans les phases de construction
et de transition.
Requis.
Ces activités sont mieux exécutées par une petite équipe composée de membres
d'une équipe inter-fonctionnelle. En général, les questions architecturalement
importantes sont la convivialité, les performances, l'évolutivité, les
processus et la synchronisation des unités d'exécution et la distribution.
L'équipe doit également inclure des membres ayant une expérience dans le
domaine qui peuvent identifier des abstractions clé.
L'équipe doit avoir une expérience de l'organisation et des couches de modèle.
Elle doit être capable de transformer ces unités disparates en une architecture
cohésive et cohérente (bien que préliminaire).
Du fait que la concentration de l'effort architectural se déplace vers des
problèmes d'implémentation, une plus grande attention doit être portée à des
questions de technologie spécifiques.
Ceci oblige l'équipe d'architecture à déplacer des membres ou à se
développer pour inclure des personnes expertes en matière de distribution et
de déploiement (si ces questions sont architecturalement importantes). Afin de
comprendre l'impact potentiel de la structure sur le modèle d'implémentation,
sur la facilité d'intégration, il est également utile de posséder de fortes
connaissances dans le processus de gestion de création logicielle.
Parallèlement, il est essentiel que l'équipe d'architecture ne soit pas
trop étendue. La stratégie pour parer à cette tendance consiste à garder un
noyau relativement petit avec un groupe satellite de membres de l'équipe
étendue qui sont appelés comme "consultants" lors de problèmes
majeurs. Cette structure fonctionne également bien avec des projets
plus petits dans lesquels une expertise particulière peut être empruntée ou
contractée auprès d'autres organisations. Elle peut être intégrée lorsque des
problèmes spécifiques doivent être résolus.
Le travail est mieux effectué en plusieurs sessions, parfois exécutées en
quelques jours (ou semaines, ou mois pour les très grands systèmes).
L'accent est mis sur les activités
Identification des mécanismes de
conception et Identification des
éléments de conception, avec un grand nombre d'itérations avec l'activité
Incorporation des éléments de conception
existants pour s'assurer que de nouveaux éléments ne dupliquent pas la
fonctionnalité des éléments existants.
A l'émergence de la conception, des problèmes de simultanéité et de
distribution sont respectivement introduits dans les activités
Description de l'architecture
d'exécution et Description de la
distribution.
Pour prendre en compte ces problèmes, des changements de conception des
éléments peuvent être requis pour répartir le comportement sur les processus,
les unités d'exécution ou les noeuds.
Comme les modèles individuels sont détaillés pour incorporer les décisions
architecturales, les résultats sont documentés dans des sections des vues
respectives dans le document d'architecture logicielle (autrement dit, comme
le modèle de conception est détaillé, la vue logique du document
d'architecture logicielle l'est également).
L'architecture résultante est révisée.
|