Tâche: Réviser l'architecture
Cette tâche définit quand et comment procéder à la revue d'une architecture et comment traiter les résultats de la revue.
Disciplines: Analyse et conception
Objet
  • Identifier tous les risques, inconnus ou perçus, dans le planning ou le budget.
  • Détecter les défauts de conception de l'architecture. Les problèmes de conception sont réputés pour être les plus difficiles à régler, et les plus lourds de conséquence à long terme.
  • Détecter une discordance possible entre les exigences et l'architecture : conception abusive, exigences non réalistes ou manquantes. En particulier, l'évaluation peut examiner certains aspects souvent négligés des opérations, de l'administration ou de la maintenance. Comment le système est-il installé ? Mis à jour ? Comment effectuer la transition à partir des bases de données actuelles ?
  • Evaluer une ou plusieurs qualités spécifiques de l'architecture : performances, fiabilité, capacité à être modifiée, sûreté et sécurité.
  • Identifier les opportunités de réutilisation
Relations
RôlesExécutant principal: Exécutant supplémentaires:
EntréesObligatoire: Facultatif:
Sorties
Utilisation des processus
Etapes
Recommandations générales
Objet Recommandations générales pour chaque revue.

De loin, pas grand-chose ne distingue une évaluation d'architecture logicielle d'une autre évaluation ou revue.

En revanche, une caractéristique importante de l'architecture logicielle est l'absence de mesures spécifiques pour de nombreux attributs de qualité de l'architecture. Seules quelques qualités de l'architecture peuvent être mesurées objectivement. Les performances constituent un exemple de qualité mesurable. Certaines autres qualités sont plus qualitatives ou subjectives. C'est le cas de l'intégrité conceptuelle par exemple. De plus, il est souvent difficile de déterminer la signification d'une mesure en l'absence de données supplémentaires ou de références de comparaison. Si un système de référence est disponible et qu'il est compris par le public cible, il est souvent utile d'exprimer certains des résultats de la revue avec ce système de référence. Cela peut-être le cas lorsque le système en cours de conception peut être comparé à une conception antérieure.

Lorsque l'évaluation est effectuée au cours du cycle de vie, elle affecte également son objet ou son utilité.

Diagramme de l'itération du cycle de vie du projet

  1. A la fin de la phase de création d'un cycle de développement initial, l'architecture concrète en place est généralement très réduite. Une revue peut cependant identifier des objectifs non réalistes, des pièces manquantes, des possibilité de réutiliser des produits existants, etc.
  2. La fin de la phase d'élaboration est le moment le plus logique pour procéder à une évaluation de l'architecture logicielle. Cette phase est principalement axée sur l'exploration détaillée des exigences et le référencement d'une architecture. Une revue d'architecture est décidée par le processus RUP à ce jalon. C'est le cas lorsque de nombreuses qualités architecturales sont évaluées.
  3. Des évaluations plus approfondies peuvent avoir lieu lors de la phase de construction afin d'examiner des attributs qualitatifs spécifiques, les performances ou la sécurité par exemple, ainsi qu'à la fin de la phase de construction pour identifier tous les problèmes pouvant empêcher de délivrer le produit à ses utilisateurs.
  4. Les évaluations de dommages peuvent avoir lieu lors des phases de construction ou même de transition, lorsque les choses ont vraiment mal tourné : construction inachevée ou nombre de problèmes inacceptable dans la base installée lors de la transition.
  5. Pour finir, vous pouvez effectuer une évaluation à la fin de la phase de transition, plus particulièrement pour faire l'inventaire des éléments qu'il serait possible de réutiliser pour un nouveau produit éventuel ou lors d'un cycle d'évolution.

Le réviseur "pair" a le même profil de personnel que le rôle : Architecte logiciel, mais il se concentre plus spécifiquement sur les problèmes techniques. Le leadership, la maturité, le pragmatisme et la concentration sur les résultats sont moins importants mais néanmoins indispensables. Un réviseur peut détecter des défauts d'architecture susceptibles de ne pas être appréciés s'ils mettent en péril le planning du projet. Il est cependant préférable de détecter les problèmes critiques tôt, lorsqu'ils peuvent être résolus, que de suivre aveuglément un planning menant l'équipe de projet dans une impasse. Le réviseur d'architecture doit peser les risques par rapport aux coûts, en restant à l'écoute des problèmes généraux relatifs au succès du projet. Il doit savoir communiquer de façon persuasive et identifier et traiter les problèmes sensibles.

Réunions de revue recommandées
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).

Affecter les responsabilités pour la résolution des problèmes
Objet Agir sur les problèmes identifiés. 

Après la revue, affectez les responsabilités pour chaque problème identifié. Dans ce cas, "responsabilité" ne signifie pas nécessairement résoudre le problème mais coordonner la recherche d'alternatives ou coordonner sa résolution si sa portée est importante.



Plus d'informations