web-dev-qa-db-fra.com

Que faut-il inclure dans une liste de contrôle de l'architecture d'application?

J'essaie de trouver une liste de contrôle ou un ensemble de questions/critères pour évaluer et évaluer les architectures proposées ou émergentes (effectuer des revues d'architecture). Quelles sont les questions les plus importantes que vous posez lorsque vous essayez de planifier, d'évaluer ou de réviser une architecture?

Je sais que c'est un sujet important, donc j'aimerais le limiter à un seul système de bout en bout et non à l'architecture pour une organisation entière.

Code complet fournit un point de départ décent:

Architecture

  • L'organisation générale du programme est-elle claire, y compris un bon aperçu architectural et une justification?
  • Les modules sont-ils bien définis, y compris leurs fonctionnalités et leurs interfaces avec d'autres modules?
  • Toutes les fonctions énumérées dans les exigences sont-elles couvertes de manière raisonnable, ni trop, ni trop peu de modules?
  • L'architecture est-elle conçue pour s'adapter aux changements probables?
  • Les décisions d'achat-construction nécessaires sont-elles incluses?
  • L'architecture décrit-elle comment le code réutilisé sera conçu pour se conformer à d'autres objectifs architecturaux?
  • Toutes les principales structures de données sont-elles cachées derrière les routines d'accès?
  • L'organisation et le contenu de la base de données sont-ils justifiés?
  • Tous les algorithmes clés sont-ils décrits et justifiés?
  • Tous les objets majeurs sont-ils décrits et justifiés?
  • Une stratégie de gestion des entrées utilisateur est-elle décrite?
  • Une stratégie de traitement des E/S est-elle décrite et justifiée?
  • Les aspects clés de l'interface utilisateur sont-ils définis?
  • L'interface utilisateur est-elle modulaire afin que ses modifications n'affectent pas le reste du programme?
  • Les estimations de l'utilisation de la mémoire et une stratégie de gestion de la mémoire sont-elles décrites et justifiées?
  • L'architecture définit-elle des budgets d'espace et de vitesse pour chaque module?
  • Une stratégie de gestion des chaînes est-elle décrite et des estimations de stockage des chaînes de caractères sont-elles fournies?
  • Une stratégie cohérente de gestion des erreurs est-elle fournie?
  • Les messages d'erreur sont-ils gérés comme un ensemble pour présenter une interface utilisateur propre?
  • Un niveau de robustesse est-il spécifié?
  • Y a-t-il une partie sur ou sous-architecturée? Les attentes dans ce domaine sont-elles énoncées explicitement?
  • Les principaux objectifs du système sont-ils clairement énoncés?
  • Est-ce que toute l'architecture est liée conceptuellement?
  • La conception de haut niveau est-elle indépendante de la machine et du langage qui seront utilisés pour l'implémenter?
  • Les motivations de toutes les décisions importantes sont-elles fournies?
  • Êtes-vous, en tant que programmeur qui implémentera le système, à l'aise avec l'architecture?

Je recherche des connaissances pratiques avec des exemples, par exemple, quels ont été les points les plus douloureux d'une architecture que vous avez créée?

architecturereview
42
cwash

Sur la base de mes recherches, voici quelques listes de contrôle de revue d'architecture que j'ai trouvées qui rendent cette question un peu plus juste et fournissent un aperçu de ce qu'est une revue d'architecture. (Il semble y avoir un peu de confusion à ce sujet ici.)

Chacun de ces candidats potentiels comprend un certain nombre de catégories différentes. L'importance globale de ces catégories variera quelque peu en fonction des besoins de l'entreprise. À mon humble avis, c'est OK. Il est beaucoup moins coûteux de poser une autre question lors de l'examen d'une liste de contrôle pour un examen et de l'exclure que de passer à côté d'une question ou d'une catégorie, car cela ne semblait pas assez important pour être initialement inclus dans une liste de contrôle.

Il semble également y avoir un livre blanc écrit sur ce sujet, bien que je ne l'ai pas lu. Il tente de répondre à cette question en 11 pages environ.

De plus, un collègue a recommandé un ensemble de livres de Springer, bien que je n'en ai pas vérifié moi-même:

37
cwash

Quelques autres points à considérer:

  • Toutes les parties prenantes sont-elles identifiées? (Exemples: client, utilisateurs finaux, analystes commerciaux, concepteurs d'interface utilisateur, développeurs, testeurs, mainteneurs.) L'architecture est-elle vérifiée auprès des parties prenantes?
  • Comment l'architecture aborde-t-elle la sécurité?
  • Les exigences de disponibilité et de fiabilité sont-elles spécifiées? Comment l'architecture y répond-elle? (Exemples: temps moyen entre les pannes, temps moyen de réparation.)
  • Comment la reprise après sinistre est-elle gérée?

Deux bons livres pour plus d'idées:

3
markusk

L'architecture est-elle conforme aux directives et à la feuille de route des fournisseurs de technologie?

Vous voulez obtenir le soutien de la plateforme que vous avez choisie, pas la combattre.

par exemple. Pour les solutions centrées sur Microsoft, cela signifie documenter où et pourquoi vos choix s'écartent des Microsoft Architecture guidance .

2
Peter Stuer

Comment allez-vous le tester

2
Steven A. Lowe

Utilise-t-il les principes SOLID?

2
aleemb

Y a-t-il une seule personne qui peut être responsable de l'architecture avec suffisamment (1) de connaissances techniques de l'architecture proposée, (2) d'expérience dans la gestion des choses, (3) debout dans l'entreprise afin que ses décisions ne puissent pas être annulées par une direction qui ne le fait pas '' Je ne sais rien.

Puisque (2) et (3) ne dépendent pas vraiment de l'architecture, je trouverais la personne et lui demanderais ce qu'elle aimerait faire.

Maintenant, en supposant que vous êtes cette personne (et cela ne ressort pas clairement de votre question - cela ne s'applique que si vous pensez que vous serez toujours l'architecte en chef de cette chose pendant un certain temps), je prendrais un conseil du blog Joel On Software et rédiger une spécification de conception, avec les plans, les objectifs, les clients, expliquant les choix de conception, tout. Cela devrait clarifier la vue.

Pensées ultérieures

J'ai essayé de réfléchir un peu aux questions exactes que vous pourriez vous poser après avoir rédigé la spécification, comme "Est-il facile de mettre à jour votre projet", "Est-ce que cela permet une flexibilité dans les objectifs finaux", "Cela facilitera-t-il les choses? pour soutenir '', `` Y a-t-il des problèmes de sécurité '', etc., mais, même s'il vaut la peine de poser des questions comme celles-ci, je ne vois tout simplement pas comment ils pourraient être utilisés pour une quelconque `` évaluation '', car à part filtrer les erreurs claires Je ne pense pas spécifique question aiderait beaucoup à "évaluer l'architecture". Peut-être que votre question gagnerait à être reformulée?

0
ilya n.