<Nom du projet>
Document d'architecture de l'actif
[Cette section fournit une présentation du Document d'architecture de l'actif dans son intégralité. Elle contient l'objectif, l'étendue, les définitions, les acronymes, les abréviations, les références et la présentation du Document d'architecture de l'actif].
Ce document fournit une présentation architecturale complète de l'actif <Nom de l'actif>. Il a pour but de capturer et de diffuser les décisions architecturales pertinentes ayant été prises à propos de la composition des artefacts individuels devant être inclus dans l'actif.
[Cette section décrit les exigences et les objectifs relatifs à l'actif ayant une influence majeure sur l'architecture ; par exemple, la facilité d'emploi, le niveau de qualification requis, l'utilisation d'un produit prêt à l'emploi ou d'un actif existant et réutilisable, l'utilisation d'une représentation spécifique et standard de l'actif, etc. Elle capture également des contraintes spéciales susceptibles de s'appliquer : la stratégie de conception et d'implémentation, les outils de développement, la structure de l'équipe, la planification et les artefacts existants].
[Cette section décrit les environnements/contextes dans lesquels l'actif doit être appliqué : le contexte de développement, de déploiement, du domaine métier, etc.
Vous trouverez ci-dessous quelques contextes dont la capture des valeurs peut être envisagée :
- Contexte de déploiement : identifie les serveurs et l'environnement d'exécution auxquels l'actif est destiné, tel que "websphere"
Contexte de développement : identifie l'environnement de développement dans lequel l'actif doit être développé/étendu
- Contexte du domaine : identifie le domaine métier de l'actif, tel que "assurance"
- Contexte de portée de réutilisation : identifie à quel niveau de l'organisation l'actif doit être réutilisé, tel que l'équipe du projet, le service et l'entreprise
- Contexte de test : identifie les contextes dans lesquels l'actif doit être testé, tels que "test de charge", "test de performances", "test fonctionnel"]
[Cette section décrit et établit les relations possibles entre l'actif et d'autres actifs. Par exemple, il peut dépendre d'un autre actif pour fournir un service spécifique, ou il peut aussi dépendre d'un autre actif qui est appliqué avant qu'il ne le soit à son tour].
[Cette section décrit comment le consommateur de l'actif doit l'utiliser. Elle peut servir de modèle d'utilisation initiale de l'actif].
[Cette section présente le modèle de cas d'utilisation de l'actif. Elle répertorie les acteurs de l'actif (c'est-à-dire, les consommateurs de l'actif) et les cas ou scénarios d'utilisation (décrivant comment l'acteur utilise l'actif). Il doit figurer une correspondance directe entre les cas d'utilisation et les fonctions de la vision de l'actif].
[Cette section illustre le fonctionnement réel de l'actif en mentionnant quelques applications de cas d'utilisation (ou des scénarios) et explique comment les différents artefacts de l'actif contribuent à leur fonctionnalité.
Dans le contexte d'un actif réutilisable, les réalisations de cas d'utilisation décrivent comment les artefacts de l'actif contribuent à fournir la fonctionnalité décrite dans le cas d'utilisation].
[Cette section répertorie la priorité relative de chacune des fonctions de l'actif décrites dans la section Modèle d'utilisation. Ces informations sont utilisées au cours de la planification des itérations pour le développement des artefacts de l'actif].
[Cette section décrit l'organisation logique complète de l'actif, ainsi que ses artefacts. En plus de la documentation fournie pour la hiérarchie du package, la raison expliquant l'organisation doit aussi être documentée].
[Cette section décrit l'organisation logique complète de l'actif, y compris la hiérarchie du package et toute autre relation importante existant entre ces packages]
[Pour chaque package, vous devez ajouter une sous-section contenant son nom, une brève description et une liste de tous les artefacts d'actif (et éventuellement ses sous-packages) qu'il contient.
Pour chaque artefact d'actif inclus dans le package, vous devez indiquer son nom, une brève description et toute relation avec d'autres artefacts].
[Cette section décrit l'organisation physique complète de l'actif (c'est-à-dire, les fichiers et les répertoires de l'actif).
L'organisation physique de l'actif est généralement différente de l'organisation logique, étant donné que son organisation physique est affectée par le choix du format à utiliser pour son packaging (par exemple, la spécification des actifs réutilisables). Par conséquent, l'organisation physique n'est généralement pas définie "à l'avance", mais elle est documentée juste avant le packaging de l'actif (ou immédiatement après).
[Cette section décrit l'organisation physique complète de l'actif. Elle répertorie les répertoires physiques qui contiennent les fichiers de l'actif, ainsi que toute "règle" régissant les fichiers à inclure dans tel répertoire.
Si une représentation standard a été sélectionnée pour l'actif, les effets sur l'organisation physique de cet actif doivent être décrits ici].
[Pour chaque répertoire physique, vous devez ajouter une sous-section contenant son nom, une brève description et une liste de tous les fichiers (et éventuellement ses sous-répertoires) qu'il contient.
[Si l'actif fournit des options de personnalisation explicites pour des contextes spécifiques (par exemple, l'instanciation de l'infrastructure architecturale à l'aide d'une base de données d'arrière-plan spécifique ou l'instanciation d'un service de déploiement pour un produit spécifique), cette section doit décrire ces options de personnalisation.
Elle doit clairement décrire ce qui est personnalisable et ensuite fournir des instructions pour effectuer cette personnalisation. Par exemple, dans le cas d'un actif représentant un modèle ou une infrastructure, cette section doit décrire les paramètres formels qui doivent être associés aux paramètres en cours dans le cadre de l'instanciation de l'actif, mais elle doit également fournir des suggestions concernant leur association. Des instructions d'utilisation détaillées sont inutiles ici car elles seront disponibles dans la documentation complète de l'actif. L'objectif ici consiste à identifier les aspects de l'actif qui doivent être personnalisés.