Quelle est la bonne méthode pour évaluer une architecture légère?

Je connais les méthodes d'évaluation de l'architecture telles que la méthode technique d' analyse de compromis d'architecture (ATAM) et la méthode d'analyse des avantages et des coûts (CBAM) plus orientée métier . Cependant, ces méthodes sont assez grandes: elles prescrivent plusieurs sessions de brainstorming, des présentations, le développement d'une multitude de scénarios décrivant les compromis, etc. développé par une poignée de développeurs (ou moins), qui même s'ils sont petits, ont des contraintes de qualité assez fortes (performances, évolutivité, adaptabilité).

Une pratique typique que j'ai utilisée dans le passé est d'avoir un développeur (ou l'architecte si une équipe en a un) pour proposer une architecture générale pour l'application, puis en discuter sur un tableau blanc avec le reste de l'équipe, en utilisant généralement une notation pseudo-UML facile à dessiner et à comprendre. Cela conduit généralement à des commentaires et à des itérations sur l'architecture. Mais elle a tendance à être un peu trop informelle, ce qui fait que toutes sortes d'hypothèses peuvent être émises, qui peuvent par la suite se révéler être de mauvaises décisions.

Des méthodes telles que ATAM obligent généralement toutes les parties prenantes à réfléchir profondément sur l'architecture, ce qui conduit à des discussions jusqu'à ce que tout le monde au moins d' accord sur ce que l'architecture exactement est .

Quelqu'un a-t-il de l'expérience dans l'évaluation de l'architecture légère d'avance? Si oui, quelles sont les bonnes pratiques?

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.

J'aime les discussions informelles sur le tableau blanc pour commencer. J'aime n'écrire que la partie de l'application qui est nécessaire aujourd'hui et laisser progressivement émerger l'architecture au cours de la mise en œuvre. C'est plus comme "trouver l'architecture", plutôt que d'essayer de l'inventer au préalable. Cette approche ne nécessite pas beaucoup d'évaluation initiale et permet de rester concentré sur ce qui est important (fournir un logiciel fonctionnel).

Bien sûr, si vos besoins non fonctionnels l'exigent (contraintes de mémoire, temps de réponse, nombre d'utilisateurs simultanés, etc.), vous devez en tenir compte lors de la mise en œuvre du système.