SAAM
SAAM is an acronym for English " s oftware a rchitecture a nalysis m ethod" . The process was developed by Rick Kazman, Gregory Abowd, Len Bass and Paul Clements.
Brief description
SAAM is the first published and one of the simpler procedures for scenario-based architecture assessment . SAAM is suitable for examining software architectures with regard to qualitative requirements such as availability, modifiability, performance, security, testability and usability, but also for evaluating the range of functions (functional requirements of a software (architecture)). Basically, in a SAAM assessment, scenarios are collected, prioritized and assigned to the parts of the software architecture to be examined that are affected by them . This can already indicate problems in the architecture:
- Components to which many scenarios have been assigned may be problematic
- Architectural decisions that lead to a scenario being assigned to many components may be problematic
For the changes that have to be made to the architecture for the respective scenarios, the change effort or an associated size is estimated.
The process of assigning scenarios to components can also lead to an improvement in the architecture documentation . The evaluation begins with an existing architecture documentation. If this is not sufficiently detailed for a meaningful assignment, the corresponding parts of the architecture are documented more precisely.
Another advantage of a SAAM evaluation is that it improves communication between the project participants: The evaluation process brings the project participants together in meetings and enables them to discuss their wishes, suggestions and criticisms for the future development of the system with one another. The architecture description serves as a common language for those involved in the project. For this reason alone, it must be described in a form that is understandable for those involved in the project.
target
The aim of the software architecture evaluation is to examine a software architecture for a certain quality feature (or several quality features at the same time). Possible research objectives are:
- Comparison of two alternative software architectures with regard to the quality characteristic (s)
- Investigation of the extent to which a software architecture fulfills certain quality characteristics
- Investigation of risks that a software architecture entails with regard to certain quality characteristics
- Investigation of the extent to which the specified software architecture in the code was also adhered to
Procedure
There are several approaches to evaluating software architectures:
Procedure for a SAAM assessment
Description of the architecture (step 1)
The architecture description should contain the following elements of the architecture in a notation that the evaluation participants can understand:
- Components and data elements
- Connections between these
- Description of the system behavior (colloquial or formal)
The architecture description can encourage those involved in the project to formulate scenarios.
Collect scenarios (step 2)
The scenarios are used to describe the activities that the system has to support at the moment or which may be supported in the future. Therefore, you should consider the tasks of various project participants (e.g. users, clients, marketing, administrators, developers, maintenance staff, etc.) as comprehensively as possible. The scenarios are collected in a meeting of representatives of the various stakeholders in a brainstorming-like process. If a more precise architecture description is required for a scenario, it is necessary to return to step 1 to prepare a detailed architecture description. Then, using the detailed documentation, step 2 is carried out again.
Classification and prioritization of the scenarios (step 3)
Scenarios are divided into two categories:
- Direct scenarios, i.e. H. Scenarios that can be run with the existing architecture without changes
- Indirect scenarios (change cases or growth cases), d. H. Scenarios that require architectural changes to be made to run.
The prioritization of the scenarios serves an efficient architecture evaluation: only the most important scenarios (e.g. the most important 30% of the scenarios) are examined more closely. The prioritization takes place through coordination among the project participants. SAAM proposes an open vote here.
Individual assessment of the scenarios (step 4)
The scenarios selected for evaluation in the previous step are assigned to the affected elements of the architecture: For a direct scenario, this means a description of the execution of the scenario by the system. For an indirect scenario, this means a description of the changes to the architecture required to execute the scenario. The necessary changes are identified and the change effort is estimated.
Investigation of scenario interactions (step 5)
Scenario interaction means that two or more scenarios require changes to the same component of the architecture. A high level of scenario interaction can indicate two different problems: A component implements several functional areas that do not belong together. The architecture of a component is not documented in sufficient detail. In this case, step 1 of SAAM (architecture description) should be carried out again.
Creation of the overall assessment (step 6)
The assessed scenarios are weighted to create the overall assessment. These weights are used to relativize the change costs for the individual scenarios.
Also known as "Saam" inharmonics.
Individual evidence
- ↑ http://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm%7Ctitle= http://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm | author = Rick Kazman, Gregory Abowd, Len Bass, Paul Clements | accessdate = 2006-10-22