Points de contrôle : Plan d'architecture logicielle
Rubriques
Dans l'ensemble, le système a une base architecturale solide, car :
- L'architecture semble être stable.
Le besoin de stabilité est dicté par la nature de la phase de construction : généralement, pendant la construction le projet s'étend, en ajoutant des développeurs qui travailleront en parallèle, communiquant modérément avec d'autres développeurs lorsqu'ils construisent le produit. Le degré d'indépendance et de parallélisme nécessaire en construction ne peut tout simplement être atteint si l'architecture n'est pas stable.
On ne peut trop insister sur l'importance d'une architecture stable. Ne pensez pas que "presque suffisant suffit" - instable est instable, et il vaut mieux soigner l'architecture et retarder le début de la construction plutôt que de continuer. Les problèmes de coordination liés à la réparation de l'architecture lorsque les développeurs essayent de construire sa base supprimeront largement tous les avantages liés à l'accélération du planning. Les changements effectués à l'architecture pendant la construction ont un impact important : ils sont généralement chers, destructeurs et démoralisants.
La véritable difficulté de l'évaluation de la stabilité architecturale réside dans le fait que "vous ne savez pas ce que vous ne savez pas"; la stabilité est mesurée par rapport au changement prévu. Ainsi, la stabilité est essentiellement une mesure subjective. Cependant, nous pouvons baser cette subjectivité sur plus qu'une simple conjecture. L'architecture elle-même est développée en envisageant des scénarios "significatifs du point de vue architectural" - des sous-ensembles de cas d'utilisation qui représentent le comportement le plus complexe que le système puisse prendre en charge du point de vue technologique. Pour évaluer la stabilité de l'architecture il faut s'assurer que l'architecture a une large couverture afin de s'assurer qu'il n'y aura pas de "surprises" lorsque l'architecture évoluera.
L'expérience passée avec l'architecture peut également être un bon indicateur : si le taux de changement dans l'architecture est faible, et reste faible lorsque de nouveaux scénarios sont couverts, on peut penser que l'architecture se stabilise. Au contraire, si chaque nouveau scénario entraîne des changements dans l'architecture, elle évolue encore et la configuration n'est pas encore garantie.
- La complexité du système correspond à la fonctionnalité qu'il fournit.
- La complexité conceptuelle est appropriée selon l'expérience et les compétences de ses :
- utilisateurs
- opérateurs
- développeurs
- Le système a une seule architecture cohérente et logique
- Le nombre et les types de composants sont raisonnables
- Le système a une fonction de sécurité logique fonctionnant sur l'ensemble du système. Tous les composants travaillent en collaboration pour sauvegarder le système.
- Le système atteindra ses cibles de disponibilité
- L'architecture permet au système de récupérer d'un échec dans le délai requis.
- Les produits et les techniques sur lesquels le système se base correspondent-ils à sa durée de vie prévue ?
- Un système provisoire (tactique) d'une durée de vie limitée peut être construit sans danger en utilisant des anciennes technologies car il sera bientôt abandonné.
- Un système avec une longue durée de vie (la majorité des systèmes) doit être construit avec une technologie et des méthodes récentes afin de pouvoir le gérer et l'étendre pour prendre en charge les exigences futures.
- L'architecture fournie définit des interfaces claires pour permettre le découpage pour un développement parallèle en équipe.
- Le concepteur d'un élément de modèle peut obtenir assez d'informations à partir de l'architecture pour concevoir et développer correctement l'élément de modèle.
- L'approche concernant les packages réduit la complexité et améliore la compréhension.
- Les packages ont été définis afin d'être hautement cohésifs dans le package-même, les packages eux-mêmes étant faiblement liés.
- Des solutions similaires pour des domaines d'applications communs ont été envisagées.
- La solution proposée peut être facilement comprise par une personne ayant des connaissances générales du domaine du problème.
- Tous les membres de l'équipe partagent la même vision de l'architecture que celle présentée par l'architecte logiciel.
- Le plan d'architecture logicielle est actualisé.
- Les recommandations de conception ont été suivies.
- Tous les risques techniques ont été limités ou bien traités dans un plan d'urgence. Les nouveaux risques découverts ont été documentés et analysés pour leur impact potentiel.
- Les exigences de performance clé (budgets établis) ont été satisfaites.
- Les jeux d'essai, routines de test et configurations de test ont été identifiés.
- L'architecture ne semble pas être "sur-conçue".
- Les mécanismes en place semblent être relativement faciles à utiliser.
- Le nombre des mécanismes est modeste et logique par rapport à la portée du système et aux exigences du domaine du problème.
- Toutes les réalisations de cas d'utilisation définies pour l'itération actuelle peuvent être exécutées par l'architecture, comme le montrent les diagrammes décrivant :
- Les interactions entre les objets,
- Les interactions entre les tâches et les processus,
- Les interactions entre les noeuds physiques.
Globalité
- Le partitionnement et la division en couches des sous-systèmes et des packages est logique et cohérent.
- Tous les mécanismes d'analyse ont été identifiés et décrits.
Sous-systèmes
- Les services (interfaces) des sous-systèmes des couches supérieures ont été définis.
- Les dépendances entre les sous-systèmes et les packages correspondent aux relations de dépendance entre les classes imbriquées.
- Les classes d'un sous-système prennent en charge les services identifiés pour le sous-système.
Classes
- Les classes d'entité clé et leurs relations ont été identifiées.
- Les relations entre les classes d'entité clé ont été définies.
- Le nom et la description de chaque classe reflètent clairement le rôle qu'elle joue.
- La description de chaque classe exprime correctement les responsabilités de la classe.
- Les classes d'entité ont été mappées aux mécanismes d'analyse lorsque c'était approprié.
- Les noms de rôle des agrégations et des associations décrivent correctement la relation entre les classes associées.
- Les multiplicités des relations sont correctes.
- Les classes d'entité clé et leurs relations sont cohérentes par rapport au modèle métier (s'il existe), le modèle de domaine (s'il existe), les exigences, et les entrées du glossaire.
- Le modèle possède un niveau approprié de détails par rapport à ses objectifs.
- Pour le modèle métier, le modèle des exigences ou le modèle de conception pendant la phase d'élaboration, il s'agit de ne pas trop insister sur les problèmes d'implémentation.
- Pour le modèle de conception dans la phase de construction, les fonctionnalités sont bien équilibrées entre les éléments de modèle, en utilisant la composition d'éléments relativement simples pour construire un système plus complexe.
- Le modèle fait preuve d'une familiarité et de compétences par rapport à la gamme complète de concepts de modélisation applicables au domaine du problème : les techniques de modélisation sont utilisées de façon appropriées pour le problème posé.
- Les concepts sont modélisés de la façon la plus simple possible.
- Le modèle évolue facilement ; les changements prévus peuvent être adoptés facilement.
- En même temps, le modèle n'a pas été trop structuré pour gérer des changements peu probables aux dépens de la simplicité et de l'intelligibilité.
- Les suppositions clé formant la base du modèle sont documentées et visibles aux réviseurs du modèle. Si ces suppositions sont applicables à une itération donnée, le modèle doit pouvoir évoluer dans le cadre de ces suppositions, mais pas nécessairement à l'extérieur de leur cadre. Documenter les suppositions permet de dispenser les concepteurs d'examiner "toutes" les exigences possibles. Dans un processus itératif, il est impossible d'analyser toutes les exigences possibles, et de définir un modèle qui gérera toute exigence future.
- L'objectif du diagramme est clairement défini et facile à comprendre.
- La présentation graphique est nette et exprime clairement l'information souhaitée.
- Le diagramme exprime suffisamment pour atteindre son objectif, mais pas plus.
- L'encapsulation est utilisée avec succès pour cacher les détails et améliorer la clarté.
- L'abstraction est utilisée avec succès pour cacher les détails et améliorer la clarté.
- Le positionnement des éléments de modèle exprime très bien les relations ; les éléments similaires ou fortement liés sont regroupés.
- Les relations entre les éléments de modèle sont faciles à comprendre.
- L'étiquetage des éléments de modèle facilite la compréhension.
- Chaque élément de modèle a un objectif distinct.
- Il n'y a pas d'élément de modèle superflu ; chacun joue un rôle essentiel dans le système.
- Pour chaque erreur ou exception, une règle définit comment le système revient à un état "normal".
- Pour chaque type d'erreur d'entrée possible de l'utilisateur ou des données incorrectes des systèmes externes, une règle définit comment le système revient à un état "normal".
- Une règle est invariablement appliquée dans le cas de situations exceptionnelles.
- Une règle est invariablement appliquée dans le cas de données corrompues dans la base de données.
- Une règle est invariablement appliquée dans le cas d'une indisponibilité de la base de données, déterminant notamment si les données peuvent être saisies dans le système et stockées plus tard.
- Si les systèmes échangent des données, il existe une règle de synchronisation des vues des données.
- Si le système utilise des processus ou des noeuds redondants pour apporter une tolérance aux pannes ou une disponibilité élevée, il existe une stratégie permettant de s'assurer que deux processeurs ou noeuds ne puissent pas "penser" qu'ils sont primaires, ou qu'aucun processeur ni noeud n'est primaire.
- Les modes d'échec pour un système réparti ont été identifiés et des stratégies ont été définies pour gérer les échecs.
- Le processus de mise à niveau d'un système existant sans perte de données ni capacité opérationnelle est défini et a été testé.
- Le processus de conversion des données utilisées par les versions précédentes est défini et a été testé.
- La quantité de temps et de ressources nécessaires pour mettre le produit à niveau ou l'installer est bien compris et documenté.
- La fonctionnalité du système peut être activée cas d'utilisation par cas d'utilisation.
- L'espace disque peut être réorganisé ou récupéré lorsque le système s'exécute.
- Les responsabilités et les procédures de configuration système ont été identifiées et documentées.
- L'accès au système d'exploitation ou aux fonctions d'administrations est restreint.
- Les exigences en terme de licence sont satisfaites.
- Les sous-programmes de diagnostics peuvent être exécutés lorsque le système s'exécute.
- Le système contrôle la performance opérationnelle elle-même (c'est-à-dire le seuil de capacité, le seuil de performance critique, l'épuisement des ressources).
- Les actions à prendre lorsque les seuils sont atteints sont définies.
- La règle de traitement des alarmes est définie.
- Le mécanisme de traitement des alarmes est défini et a été prototypé et testé.
- Le mécanisme de traitement des alarmes peut être "réglé" pour éviter les fausses alarmes ou les alarmes redondantes.
- Les règles et les procédures pour le contrôle et l'administration des réseaux (LAN, WAN) sont définies.
- Les erreurs du réseau peuvent être isolées.
- Une fonction de suivi des erreurs peut être activée pour faciliter le dépannage.
- Le temps système de la fonction est bien compris.
- L'équipe d'administration possède les connaissances nécessaires pour utiliser la fonction efficacement.
- Un utilisateur malveillant ne peut :
- entrer dans le système.
- détruire des données cruciales.
- consommer toutes les ressources.
- Les exigences de performance sont raisonnables et reflètent les véritables contraintes du domaine du problème ; leur spécification n'est pas arbitraire.
- Il existe des estimations de performance système (modélisées selon les besoins en utilisant un modèle d'analyse de la charge de travail), qui indiquent que les exigences de performance ne sont pas des risques significatifs.
- Les estimations en terme de performance système ont été validées en utilisant des prototypes architecturaux, en particulier pour les exigences essentielles pour la performance.
- Des budgets mémoire pour l'application ont été définis.
- Des actions ont été entreprises pour détecter et éviter les fuites de mémoire.
- Une règle est invariablement appliquée pour définir la façon dont le système de mémoire virtuelle est utilisé, contrôlé et réglé.
- Le véritable nombre de lignes de code développé correspond jusqu'à présent aux lignes de code estimées pour cet événement jalon.
- Les suppositions d'estimation ont été revues et restent valides.
- Les estimations de coût et de planning ont été re-calculées en utilisant l'expérience de projet et la performance de productivité réelles les plus récentes.
- Les exigences de portabilité ont été satisfaites.
- Les recommandations de programmation fournissent des conseils spécifiques pour la création de code portable.
- Les recommandations de conception fournissent des conseils spécifiques pour la conception d'applications portables.
- Un "port test" a été effectué pour vérifier les réclamations en terme de portabilité.
- Les mesures de qualité (moyenne des temps de bon fonctionnement, nombre de défauts en attente, etc.) ont été satisfaites.
- L'architecture permet la reprise dans le cas d'un sinistre ou d'un échec du système
- Les exigences de sécurité ont été satisfaites.
- Les équipes sont-elles bien structurées ? Les responsabilités sont-elles bien réparties entre les équipes ?
- Existe-t-il des problèmes politiques, organisationnels ou administratifs qui limitent l'efficacité des équipes ?
- Existe-t-il des conflits de personnalité ?
La section vue de cas d'utilisation du plan d'architecture logicielle :
- chaque cas d'utilisation est significatif du point de vue architectural, et identifié en tant que tel car il :
- est crucial pour le client
- justifie des éléments clé dans les autres vues
- agit sur la limitation d'un ou de plusieurs risques majeurs, y compris les exigences non-fonctionnelles importantes.
- il n'existe aucun cas d'utilisation pour lequel les préoccupations architecturales sont déjà traitées par un autre cas d'utilisation
- les aspects du cas d'utilisation significatifs du point de vue architectural sont clairs, et ne sont pas noyés dans les détails
- le cas d'utilisation est clair et n'est pas susceptible de changer d'une façon qui influencerait l'architecture, ou bien un plan permettant d'atteindre ce type de clarté et de stabilité est déjà en place
- aucun cas d'utilisation significatif du point de vue architectural n'a été oublié (une analyse des cas d'utilisation non sélectionnés peut être nécessaire pour cette vue).
La section vue logique du plan d'architecture logicielle :
- donne une présentation appropriée et complète des éléments de la conception significatifs du point de vue architectural.
- présente l'ensemble complet de mécanismes architecturaux utilisés dans la conception ainsi que la justification de leur sélection.
- présente le découpage en couches de la conception, ainsi que la justification de ce découpage en couches.
- présente toutes les infrastructures ou modèles utilisés dans la conception, ainsi que la justification de la sélection des modèles ou infrastructures.
- Le nombre d'éléments de modèle significatifs du point de vue architectural est proportionné à la taille et à la portée du système, et sa taille permet d'expliciter les principaux concepts utilisés dans le système.
Rubriques
- La concurrence critique potentielle (concurrence de processus pour les ressources critiques) a été identifiée et des stratégies pour éviter et résoudre ce problème ont été définies.
- Une stratégie est définie pour traiter les conditions "file d'attente entrée/sortie saturée" ou de "mémoire tampon saturée".
- Le système s'auto-contrôle (seuil de la capacité, seuil de performance critique, épuisement des ressources) et est capable de prendre des mesures correctives lorsqu'un problème est détecté.
- Les exigences en terme de temps de réponse ont été identifiées pour chaque message.
- Il existe un mode diagnostic pour le système qui permet de mesurer les temps de réponse des messages.
- Des exigences de performance nominales et maximales ont été définies pour les opérations importantes.
- Un ensemble de tests de performance permet de mesurer si les exigences de performance ont été satisfaites.
- Les tests de performance couvrent le comportement "extra-normal" du système (démarrage et arrêt, flots d'événements alternatifs et exceptionnels des cas d'utilisation, modes d'échec système).
- Les faiblesses architecturales créant des goulots d'étranglement de performance potentiels ont été identifiées. On a insisté tout particulièrement sur :
- L'utilisation de ressources partagées finies comme (mais pas limitées à) les sémaphores, identificateurs de fichier, verrous, loquets, la mémoire partagée, etc.
- La communication inter-processus. La communication entre les frontières de processus est toujours plus coûteuse que la communication interne au processus.
- La communication inter-processeur. La communication entre les frontières de processus est toujours plus coûteuse que la communication inter-processus.
- L'utilisation de la mémoire physique et virtuelle ; le stade auquel le système se retrouve à cours de mémoire physique et commence à utiliser la mémoire virtuelle correspond généralement à une forte chute de la performance.
- Lorsqu'il y a des processus primaires et de sauvegarde, la possibilité qu'un processus pense qu'il est primaire (ou qu'aucun processus ne pense être primaire) a été envisagée et des actions de conception spécifiques ont été effectuées pour résoudre le conflit.
- Des processus externes restaurent le système vers un état compatible lorsqu'un événement comme un échec de processus quitte le système dans un état incompatible.
- Le système tolère les erreurs et les exceptions, de façon à ce que lorsqu'une erreur ou une exception a lieu, le système puisse revenir à un état compatible.
- Des tests de diagnostic peuvent être exécutés lorsque le système s'exécute.
- Le système peut être mis à niveau (matériel, logiciel) lorsqu'il s'exécute, si nécessaire.
- Une règle est invariablement appliquée pour le traitement des alarmes dans le système. La règle concernant l'alarme examine :
- la "sensibilité" du mécanisme de signalisation des alarmes ;
- la prévention des fausses alarmes et des alarmes redondantes ;
- les exigences en terme de formation et d'interface utilisateur de l'équipe qui utiliseront le mécanisme de signalisation des alarmes.
- L'impact de performance (cycles de processus, mémoire, etc.) du mécanisme de signalisation des alarmes a été évalué et reste dans la limite des seuils de performance acceptables établis dans les exigences de performance.
- Les exigences en terme de charge de travail/performance ont été examinées et satisfaites. Les exigences de performance non réalistes ont été re-négociées.
- Les budgets de mémoire, dans la mesure où ils existent, ont été identifiés et le logiciel a été vérifié pour répondre à ces exigences.
Des mesures ont été prises pour détecter et éviter les fuites de mémoire.
- Il existe une règle concernant l'utilisation du système de mémoire virtuelle, y compris comment le contrôler et régler son utilisation.
- Les processus sont suffisamment indépendants les uns des autres pour pouvoir être répartis entre des processeurs ou des noeuds en cas de besoin.
- Les processus devant rester co-localisés (du fait d'exigences de performance et de débit, ou du mécanisme de communication inter-processus (par exemple, les sémaphores ou la mémoire partagée) ont été identifiés, et l'impact de l'impossibilité de répartir cette charge de travail a été pris en compte.
- Les messages pouvant être rendus asynchrones, afin d'être traités lorsque les ressources sont plus disponibles, ont été identifiés.
- Les exigences de débit ont été satisfaites par la répartition du traitement entre les noeuds, et les goulots d'étranglement de performance potentiels ont été examinés.
- En cas de répartition et de la duplication potentielle de l'information entre plusieurs noeuds, l'intégrité de l'information est assurée.
- Les exigences de transport fiable des messages, sous leur forme actuelle, ont été satisfaites.
- Les exigences de transport sûr des messages, sous leur forme actuelle, ont été satisfaites.
- Le traitement a été réparti entre les noeuds de façon à minimiser le trafic réseau et le temps de réponse selon les contraintes de cohérence et de ressources.
- Les exigences de disponibilité du système, dans la mesure où elles existent, ont été satisfaites.
- Le temps d'arrêt maximum du système dans le cas d'un échec du serveur ou du réseau a été déterminé et reste dans les limites acceptables définies par les exigences.
- Les serveurs redondants ou en attente ont été définis ce façon à ce qu'il soit impossible que plus d'un serveur soit serveur "primaire".
- Tous les modèles d'échec potentiels ont été documentés.
- Les erreurs du réseau peuvent être isolées, diagnostiquées et résolues.
- La quantité d'"espace de débordement" dans l'utilisation de l'unité centrale a été identifiée et la méthode de mesure a été définie
- Il existe une règle définie pour les actions à entreprise lorsque l'utilisation maximum de l'unité centrale est dépassée.
| |
|