<Project Name>
Asset Architecture Document
[This section provides an overview of the entire Asset Architecture Document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Asset Architecture Document.]
This document provides a comprehensive architectural overview of the <name of Asset>. It is intended to capture and convey the significant architectural decisions that have been made regarding the composition of the individual artifacts that are to be included in the asset.
[This section describes the asset requirements and objectives that have some significant impact on the architecture; for example, ease of use, required skill level, use of an off-the-shelf product or existing reusable asset, use of a specific standard representation for the asset, etc. It also captures the special constraints that may apply. These include design and implementation strategy, development tools, team structure, schedule, and existing artifacts.]
[This section describes the environments/contexts the asset intended to be applied within. This includes the development context, deployment context, business domain context, etc.
Some possible contexts to consider capturing values for include:
- Deployment Context: Identifies the servers and runtime environment for which the asset is intended such as "websphere"
- Development Context: Identifies the development environment in which the asset is intended to be developed/extended
- Domain Context: Identifies business domain of the asset such as "insurance"
- Reuse Scope Context: Identifies organizationally where the asset is intended to be reused, such as, project team, department, and enterprise
- Test Context: Identifies the contexts in which the asset should be tested such as the following: "load test", "performance test", "functional test"]
[This section describes and relationships the asset may have to other assets. For example, the asset may depend on another asset to provide a specific service, or may be dependent on another asset being applied before the asset itself is applied.]
[This section describes how the asset consumer should use the asset. It can be considered an initial usage model for the asset.]
[This section contains the Use-Case Model for the asset. It lists the actors (i.e., the asset consumers) of the asset and the use cases or scenarios (descriptions of how the actor uses the asset). There should be a direct correspondence between the use cases and the features in the Asset Vision.]
[This section illustrates how the asset actually works by giving a few selected use-case (or scenario) realizations, and explains how the various asset artifacts contribute to their functionality.
In the context of a reusable asset, use-case realizations describe how the asset artifacts contribute to providing the functionality described in the use case.]
[This section lists the relative priority of each of the asset features described in the Usage Model section. This information is used during iteration planning for the development of the asset artifacts.]
[This section describes the overall logical organization of the asset, as well as lists the artifacts that are contained with the asset. In addition to documenting the package hierarchy, the rationale for the organization should also be documented.]
[This section describes the overall logical organization of the asset, including its package hierarchy and any important relationships between those packages]
[For each package, include a subsection with its name, a brief description, and a list of all of the asset artifacts (and possibly sub-packages) contained within the package.
For each asset artifact in the package, include its name, brief description, and any relationships with other asset artifacts.]
[This section describes the overall physical organization of the asset (i.e., the asset files and directories).
The physical organization of the asset is usually not the same as the logical organization, as the physical organization of the asset is impacted by the choice of what format to use to package the asset (for example, the Reusable Asset Specification). Thus, the physical organization is usually not defined "up front", but is instead documented just before the asset is packaged (or immediately after the packaging is complete).
[This describes the overall physical organization of the asset. It lists the physical directories that contain the asset files, as well as any "rules" that govern what files can be included in what directory.
If a standard asset representation has been selected for the asset, the affect on the physical organization of the asset should be described here.]
[For each physical directory, include a subsection with its name, a brief description, and a list of all of the files (and possibly sub-directories) contained within the directory.]
[If the asset provides explicit customization options for specific contexts (for example, instantiating an architectural framework with a specific back-end database, or instantiating a deployment service for a specific product), then this section should describe those customization options.
This section should explicitly describe what can be customized and then provide guidelines for performing the customization. For example, in the case of an asset that represents a template or framework, this section should describe the formal parameters that need to be bound to actual parameters as part of instantiating the asset, as well as providing suggestions on what they should be bound to. Detailed usage instructions are not required here since they will be provided in the complete asset documentation. The goal is identification of those aspects of the asset which should be customized. "built-in".]