Activité :
|
Objet
|
|
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 : |
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.
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.
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 :
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.
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.
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 :
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.
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).
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)
|