La clé d'une évaluation légère est d'évaluer les bonnes choses au bon moment. Je connais deux façons de le faire efficacement. Avec l' évaluation basée sur des scénarios, vous utilisez des scénarios d'attributs de qualité et des cas d'utilisation pour piloter l'évaluation en vous concentrant uniquement sur les attributs de qualité de haute priorité. Avec une évaluation basée sur les risques, vous identifiez les risques et laissez les risques identifiés guider vos activités de conception d'architecture.
Il y a deux livres que je peux recommander qui explorent ces deux approches (quelque peu liées).
Architecting Software Intensive Systems par Anthony Lattanze présente la méthodologie de conception centrée sur l'architecture et couvre les évaluations basées sur des scénarios légers. Vous pouvez reconnaître Lattanze de l'atelier sur les attributs de qualité du SEI et des idées similaires sont impliquées.
L'architecture logicielle juste suffisante: une approche axée sur les risques de George Fairbanks présente une approche axée sur les risques pour concevoir et évaluer l'architecture d'un système logiciel. Il y a aussi des chapitres gratuits disponibles sur son site Web si vous vouliez un aperçu. Bien que les principes de ce livre soient immédiatement applicables, l'approche ne vient pas avec une méthode spécifique, vous devrez donc combiner des idées d'autres domaines. Je recommande fortement l' approche de gestion des risques continue du SEI pour identifier / hiérarchiser les risques.
L'idée de base derrière ces approches est que vous réduisez le coût de l'évaluation (et de la conception) en évaluant au fur et à mesure plutôt qu'en attendant la fin. Bien que ce soit certainement un peu plus lourd que de parler autour d'un tableau blanc, ce n'est pas aussi cher qu'un ATAM complètement soufflé. Et si vous êtes à l'aise, vous pouvez choisir des pratiques de cerise pour répondre à vos besoins spécifiques.
Quelle que soit l'approche que vous utilisez pour conduire l'évaluation, l'idée générale sera la même ...
Avant de commencer:
- Scénarios ou risques d'attributs de qualité, hiérarchisés (peuvent être informels si c'est tout ce que vous avez)
- Définition claire de la décision "go / no go" (comment savez-vous que l'architecture est "assez bonne")
- Coupe la plus récente de la description de l'architecture (l'artefact que vous évaluez)
Asseyez-vous pour une session d'évaluation:
- Architecte présente un aperçu de l'architecture
- Parcourez une vue, montrez comment le scénario ou le risque est satisfait
- Les problèmes sont enregistrés pour être résolus plus tard
- Les rôles et la procédure générale sont similaires à ceux utilisés pour une inspection Fagan (architecte ou auteur, modérateur, enregistreur).
- La session peut prendre aussi peu qu'une heure ou deux selon la taille de votre système.
Une fois la session terminée:
- Examinez les problèmes identifiés et déterminez si les critères de non-participation sont respectés. Généralement, il faut environ 3 avis pour que tout se passe bien. S'il n'est pas atteint, continuez à affiner et à expérimenter (ou à atténuer les risques liés à l'architecture).
- Il ne s'agit pas d'une évaluation «tout ou rien» - différentes parties de votre architecture peuvent «passer» tandis que d'autres doivent encore être affinées.
Pour vous donner une idée de ce à quoi pourrait ressembler l'approche basée sur des scénarios, il existe de la documentation publique d'un projet de synthèse sur lequel j'ai travaillé à l'école doctorale. La documentation est un peu approximative, mais elle pourrait aider à donner quelques exemples de l'approche basée sur des scénarios dans le contexte d'ACDM. Nous étions une équipe de 5 personnes et avons construit une application Web typique, environ 35 KLOC Java / GWT.