Objet
|
Définir la portée et les objectifs de la revue.
Définir les approches adoptées pour chaque combinaison portée/objectif spécifique.
|
Différentes approches peuvent être utilisées pour effectuer la revue :
-
basée sur la représentation
-
basée sur les informations
-
basée sur un scénario
Revue basée sur la représentation
Obtenez (ou générez) une représentation de l'architecture puis posez des questions et des justifications en fonction de
cette représentation.
Il existe une grande variété de situations possibles, de l'organisation maîtrisant le sujet de l'architecture et en
mesure d'en fournir une description claire, à l'organisation dans laquelle vous devez identifier l'architecte logiciel
(qui peut porter un autre titre) et lui "arracher" les informations, en passant par une organisation dans laquelle le
concept d'architecture logicielle est totalement inconnu. Ce processus est alors appelé "exploitation de
l'architecture" et, en pratique, se rapproche des activités minières : extraction du logiciel ou de sa documentation
comme à la pioche, recherche du code source, des données de configuration, des interfaces, etc.
Un modèle pouvant être utilisé pour organiser la représentation est le format des vues d'architecture présentées dans
le Document d'architecture du logiciel : la vue logique organise les classes principales (le modèle d'objet), la vue du
processus décrit les unités de contrôles principales et leur mode de communication, la vue de développement affiche les
divers sous-systèmes et leurs dépendances, la vue physique décrit le mappage des éléments des autres vues vers une ou
plusieurs configurations physiques. Les problèmes sont organisés en fonction des différentes vues.
Revue basée sur les informations
Etablissez la liste des informations (données, mesures) nécessaires à la réflexion, obtenez les informations et
comparez-les aux exigences ou à certaines normes de références acceptées. Cette approche s'applique particulièrement
bien à l'étude d'attributs qualitatifs spécifiques, comme les performances ou la robustesse.
Revue basée sur un scénario
Il s'agit de l'approche systématique "que ce passe-t-il si...". Elle transforme les questions générales posées en une
série de scénarii que doit exécuter le système, et pose les questions en fonction de ces scénarii. Exemples de scénarii
:
-
Le système est exécuté sous les plateformes X et Y. (L'attribut qualitatif réellement sondé est la portabilité.)
-
Le système exécute cette fonction F (supplémentaire). (L'attribut qualitatif réellement sondé est l'extensibilité.)
-
Le système traite 200 requêtes par heure. (L'attribut qualitatif réellement sondé est l'évolutivité.)
-
Le système est en cours d'installation sur ce type de site par l'utilisateur. (L'attribut qualitatif réellement
sondé est l'exhaustivité ou la convivialité.)
L'avantage de cette approche est qu'elle offre une perspective très concrète à la tâche, que toutes les personnes
impliquées comprennent. Elle permet également d'examiner les omissions ou les imperfections des exigences, plus
particulièrement lorsque celles-ci sont informelles, non pas écrites, ou très générales et succinctes. L'inconvénient
est qu'elle ne considère pas l'architecture elle-même objet de la revue mais aborde le système comme une boîte noire
dans laquelle nous n'envoyons que des sondes.
En pratique, les choses ne sont pas aussi rigides et un mélange des trois approches est souvent utilisé.
Identification des problèmes
L'identification de problèmes potentiels repose souvent sur un jugement humain basé sur la connaissance et
l'expérience. Certain modèles d'échec se reproduisent d'un projet à un autre, d'une organisation à une autre. Certains
modèles heuristiques peuvent être utilisés pour identifier des zones à problèmes. Des listes de contrôles peuvent être
utiles (des listes très génériques sont proposées ci-après), tout comme peuvent l'être les résultats des revues
précédentes, le cas échéant.
Enregistrez les problèmes potentiels dès qu'ils sont trouvés, en les décrivant de façon neutre, sans accusation
ni "catastrophisme". Vous pouvez utiliser des cartes en carton comme les réviseurs AT&T ou des cartes CRC (Class
Responsibility Collaboration) comme nous le faisons, pour vous aider à établir des priorités, organiser et éliminer.
Ensuite, triez les problèmes potentiels par ordre décroissant de portée ou d'impact et, s'ils sont nombreux, commencez
par ceux directement liés à la question étudiée et laissez les "autres suggestions" pour plus tard, si vous en avez le
temps. Vérifiez ensuite la réalité du problème. Ce qui est perçu comme un problème n'en est pas toujours un. Il s'agit
tout simplement que la bonne personne n'a pas été contactée ou que la bonne information n'a pas été recherchée.
Effectuez un autre tri. Multipliez les points de données pour vérifier la réalité d'un problème). (Les évaluateurs
inexpérimentés ont tendance à n'utiliser qu'une seule source.)
Une fois le problème confirmé, examinez rapidement comment l'éliminer, sans nécessairement effectuer de re-conception
du système à la volée. Notez les alternatives, réutilisations et simplifications potentielles (par exemple
acheter/construire).
|