Objet
  • Découvrir les risques inconnus ou perçus dans la planification ou le budget.
  • Détecter les erreurs de conception architecturale. Les erreurs architecturales sont les plus difficiles à corriger et les plus préjudiciables à long terme.
  • Détecter un écart potentiel entre les exigences et l'architecture : conception excessive, exigences irréalisables ou absentes. L'évaluation peut examiner tout particulièrement certains aspects souvent négligés liés au fonctionnement, à l'administration et à la maintenance. Comment le système est-il installé ? Mis à jour ? Comment s'effectuent les transitions de bases de données ?
  • Evaluer une ou plusieurs qualités architecturales spécifiques : performances, fiabilité, capacité de modification, sécurité.
  • Identifier les possibilités de réutilisation
Rôle :  Auditeur technique 
Fréquence :  Une fois par itération au minimum, et tout particulièrement pendant la phase d'élaboration.
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations : 

Détails sur l'enchaînement d'activités :   

Recommandations générales Haut de la page

Objet Recommandations générales pour chaque revue.

A première vue, peu de choses distinguent une évaluation d'architecture logicielle d'une autre évaluation ou revue.

Toutefois, l'une des caractéristiques importantes de l'architecture logicielle est son manque de mesures spécifiques, qui s'applique à de nombreux attributs : seules quelques qualités architecturales peuvent être mesurées objectivement. Les performances sont un exemple de mesures qu'il est possible d'effectuer. D'autres qualités sont plus qualitatives ou subjectives : par exemple, l'intégrité conceptuelle. Par ailleurs, il est souvent difficile de déterminer la signification d'une mesure en l'absence d'autres données de référence à utiliser en comparaison. Si un système de référence est disponible et compris par le public cible, il est souvent utile d'exprimer certains résultats de la revue par rapport à ce système de référence. Cela peut se produire lorsque le système en cours de conception peut être comparé à une conception antérieure.

L'utilité et l'objectif de cette évaluation dépendent également de la phase concernée du cycle de vie.

Diagramme illustrant le cycle de vie du projet

  1. A la fin de la phase de création, au cours d'un cycle de développement initial, il existe généralement peu d'architecture concrète en place. Toutefois, une revue peut permettre de découvrir des objectifs irréalistes, des éléments manquants, des opportunités manquées de réutilisation de produits existants, etc.
  2. La phase la plus naturelle pour une évaluation d'architecture logicielle est à la fin de la phase d'élaboration. Cette phase est principalement consacrée à l'exploration détaillée des exigences et à la création de références pour une architecture. La revue d'une architecture est mandatée par RUP au niveau de ce jalon. Cela se produit lorsque de nombreuses qualités architecturales sont examinées.
  3. Des évaluations plus spécifiques peuvent avoir lieu pendant la phase de construction, pour examiner certains attributs de qualités en particulier (performances ou sécurité, par exemple), ainsi qu'à la fin de la phase de construction pour tous les thèmes susceptibles d'empêcher la livraison du produit aux utilisateurs finaux.
  4. Les évaluations de contrôle de dommages peuvent avoir lieu ultérieurement dans la phase de construction, voire au cours des phases de transition, lorsque cela s'est mal passé : la construction n'est pas complète, ou un niveau inacceptable de problèmes survient dans la base installée au cours de la transition.
  5. L'évaluation peut également avoir lieu à la fin de la phase de transition, et concerne tout particulièrement l'évaluation des ressources réutilisables pour un éventuel nouveau produit ou un nouveau cycle d'évolution.

Le réviseur pair a le même profil que le rôle d'architecte du logiciel, mais moins orienté sur les questions techniques. Les qualités de leadership, de maturité, de pragmatisme et de recherche de résultats sont également importantes : un réviseur peut découvrir des anomalies de conception qui risquent d'être impopulaires si elles menacent la planification du projet. Il est toutefois préférable de mettre à jour des situations critiques à un stade précoce, car elles peuvent être résolues ; en revanche, la poursuite aveugle du calendrier entraîne l'équipe projet dans une impasse. Le réviseur doit équilibrer les risques par rapport aux coûts, et rester sensible aux conditions menant le projet au succès. Il doit également être persuasif et pouvoir, grâce à une bonne communication, aborder des questions sensibles et mener une discussion sur ces thèmes.

Réunions de revue recommandées Haut de la page

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. 

Pour mener à bien la revue, plusieurs approches peuvent être utilisées :

  • revue par représentation
  • revue par apport d'informations
  • revue par utilisation de scénario
Revue par représentation

Elaborez ou procurez-vous une représentation de l'architecture, puis posez des questions et construisez votre raisonnement sur la base de cette représentation.

Il existe un grand nombre de situations à représenter, en commençant par les organisations donnant lieu à des descriptions intelligibles, jusqu'aux organisations qui nécessitent l'identification de l'architecte du logiciel (même masqué sous un autre nom) et l'extraction des informations relatives à cette personne, en passant par les cas où l'architecture logicielle est un concept inconnu. Ce processus est ensuite appelé "minage de l'architecture" et en pratique ressemble littéralement à cela : il s'agit de décortiquer le logiciel ou sa documentation à l'aide d'un, rechercher le code source, les interfaces, les données de configuration, etc.

Pour organiser la représentation, vous pouvez utiliser un modèle au format de vue architecturale présenté dans le document d'architecture logicielle : la vue logique organise les principales classes (modèle d'objet), la vue du processus décrit les principales unités d'exécution de contrôle et leur mode de communication, la vue de développement illustre les différents sous-systèmes et leurs dépendances, et la vue physique décrit le mappage d'éléments des autres vues en une ou plusieurs configurations physiques. Organisez les thèmes autour des différentes vues.

Revue par apport d'informations

Dressez la liste des informations et des mesures nécessaires au raisonnement, obtenez ces informations et comparez-les aux exigences ou à une norme de référence acceptée. Cela s'applique tout particulièrement à l'investigation de certains attributs de qualités, comme par exemple les performances ou la robustesse.

Revue par utilisation de scénario

Il s'agit de l'approche d'"hypothèse" systématique. Transformez les questions générales posées en scénarios exploitables par le système et posez des questions relatives à ces scénarios. Voici des exemples de ces scénarios :

  • Le système est exécuté sur les plates-formes X et Y. (L'attribut de qualité évalué est la portabilité.)
  • Le système possède la fonction supplémentaire F. (L'attribut de qualité est la capacité d'extension.)
  • Le système traite 200 demandes par heure. (L'attribut de qualité est l'évolutivité.)
  • Le système est installé sur ce type de site par l'utilisateur final. (L'attribut de qualité est l'achèvement ou la capacité d'utilisation.)

L'avantage d'une telle approche est qu'elle est très concrète et compréhensible par toutes les parties. Elle permet également de rechercher les omissions ou les erreurs au sein des exigences, surtout lorsque celles-ci sont informelles ou non écrites, ou encore très générales. L'inconvénient est qu'elle ne couvre pas l'architecture elle-même comme objet de revue, mais considère le système comme une boîte noire dans laquelle des vérifications sont effectuées.

En pratique, les choses ne sont pas aussi séparées, et les trois approches sont souvent mêlées.

Identification des anomalies

La découverte d'anomalies potentielles s'effectue principalement via le jugement humain, sur la base des connaissances et de l'expérience acquises. Certains schémas d'anomalies se répètent de projet en projet, d'organisation en organisation. Vous pouvez utiliser certaines heuristiques pour découvrir les zones contenant des problèmes. Les listes de contrôle peuvent s'avérer très utiles (certaines listes génériques sont proposées plus loin), ainsi que les résultats de revues précédentes, le cas échéant.

Enregistrez les anomalies potentielles au fur et à mesure qu'elles se présentent, et décrivez-les de façon neutre, sans catastrophisme. Vous pouvez utiliser des cartes comme le font les réviseurs AT&T ou comme nous le faisons avec les cartes CRC pour appliquer des priorités, pour effectuer des organisations ou des éliminations.

Ensuite, triez les questions potentielles par impact décroissant, et si elles sont nombreuses, traitez celles qui sont directement liées au thème traité, en laissant les "autres suggestions" pour plus tard si le temps alloué le permet. Evaluez la réalité du problème : un problème peut être perçu sans qu'il soit réellement présent. Dans ce cas, il se peut simplement que nous n'ayons pas contacté la bonne personne, ou recherché l'information appropriée. Effectuez un nouveau tri. Utilisez plusieurs points de données pour vérifier la réalité d'un problème. (Les évaluateurs inexpérimentés tendent à n'utiliser qu'un seul point.)

Une fois la présence du problème confirmée, examinez rapidement les possibilités de résolution, sans pour autant tenter de reprendre la conception du système. Ecrivez toutes les simplifications, réutilisations et solutions potentielles (par exemple, acheter ou construire).

Allouer les responsabilités de résolution d'incidents Haut de la page

Objet Exécuter les actions requises pour les anomalies identifiées. 

Une fois la revue terminée, allouez les responsabilités correspondant à chaque anomalie identifiée. Dans ce cas, la "responsabilité" peut ne pas consister à corriger l'anomalie, mais à coordonner une investigation supplémentaire ou d'autres solutions, ou encore à assurer la coordination de la résolution de l'incident si sa portée est vaste.



RUP (Rational Unified Process)   2003.06.15