Software architecture analysis method

SAAM is an acronym for (English) "software architecture analysis method". The procedure was developed by Rick Kazman, Gregory Abowd, Len Bass and Paul Clements.

Short description SAAM

SAAM is the first published and one of the simpler methods for scenario-based architecture evaluation. SAAM is suitable for the study of software architectures in terms of quality requirements such as availability ( availability), modifiability ( Modifyability ), Performance, Security ( Security), testability ( Testability ) and usability (usability) but also for the evaluation of the functional scope (functional requirements of a software. ( architecture ) In principle, levied at a SAAM evaluation scenarios, prioritized and allocated to the relevant parts of them to be tested software architecture early as this can indicate problems in architecture.:

  • The problem may be components that many scenarios were assigned
  • The problem may be architectural decisions that lead to a scenario has been assigned to many components

For changes to be made ​​to the architecture of the respective scenario, the change of effort, or a related quantity is estimated.

The process of assigning scenarios to components can also lead to an improvement in the architecture documentation. The assessment begins with a pre-existing architecture documentation. Is this a sensible allocation not sufficiently detailed, relevant parts of the architecture are documented in more detail.

Another advantage of a SAAM evaluation is that they the communication between the project participants improved: The evaluation process brings the project participants in meetings and gives them their wishes, suggestions and criticisms for the future development of the system to discuss with each other. The architecture description is used as a common language for the project participants. For this reason alone it must be described in a form understandable to the stakeholders.

Goal of SAAM

Goal of the software architecture evaluation is to examine a software architecture to a specific quality characteristic ( or more quality characteristics simultaneously) out. Possible research goals are:

  • Comparison of two alternative software architectures with respect to the quality characteristic / quality characteristics
  • Study the extent to which a software architecture meets specific quality criteria
  • Analysis of risks associated with a software architecture with respect to certain quality characteristics to
  • Study the extent to which the specified software architecture is also maintained in the code

Method for SAAM

For the evaluation of software architectures, there are several approaches:

  • Questionnaires
  • Checklists
  • Scenario-based software architecture evaluation
  • Architecture metrics

Expiration of a SAAM evaluation

Scenarios raise (step 1)

The scenarios are used to describe the activities that must support the system currently or will eventually help in the future. Therefore, they should consider the tasks of various project participants (eg user, customer, marketing, administrator, developer, 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. Where a more detailed architecture description needed for a scenario, it proceeds to step 2 and then returns to step 1 ( iterative execution of step 1 and 2).

Description of the architecture (step 2)

The architecture description should contain the following elements of the architecture in a notation understandable to the evaluation participants:

  • Components and data elements
  • Connections between these
  • Description of the system behavior (colloquial or formal)

The architecture description can stimulate the stakeholders for the formulation of scenarios. For this reason, we recommend an iterative execution of steps 1 and 2

Classification and prioritization of scenarios (Step 3)

Scenarios are divided into two categories:

  • Direct scenario, that is, Scenarios which can be carried out with the existing architecture without modification
  • Indirect scenarios (Change or Growth Cases Cases), ie Scenario, the performance of which architectural changes need to be made.

The prioritization of the scenarios is an efficient architecture evaluation: only the most important scenarios (eg, the most important 30 % of the scenarios ) are examined more closely. The prioritization done by a vote among the project participants. SAAM proposes an open vote here.

Individual assessment of the scenario ( step 4)

The in the previous step to evaluate selected scenarios are divided between the relevant elements of architecture: For a direct scenario, this means a description of the execution of the scenario through the system. For an indirect scenario, this means a description of the necessary for the execution of the scenario changes to the architecture. The necessary changes are identified and estimated the change effort.

Investigation of scenario interactions (step 5)

Scenario interaction means that two or more scenario, changes to the same component of the architecture. A high scenario interaction can refer to two different problems: A component implements several non- related functional areas. The architecture of a component is not sufficiently well documented. In this case, step 2 should be run by SAAM (architectural description) again.

Creation of Overall (step 6)

To establish the overall assessment evaluated scenarios are weighted. These weights are used to relativize the change effort for each scenario.

Also known as " Saam'sche " inharmonious.

Software metric
699679
de