SAAM은 단순한 방법론이다. 특히 아키텍쳐 평가 경험이 없는 경우에 적용하기 적합하다.
아키텍쳐에 대한 modifiability나 functionality를 평가하는 목적이라면 ATAM보다 유용하다.
만약 S/W아키텍쳐와 infra아키텍쳐가 별도의 조직에 의해 유지되는 경우에 ATAM을 적용하게 되면 이해관계가 충돌하거나 오히려 평가의 본래 목적을 달성하지 못할 수 있다.이런 상황에서 Application Framework이나 공통 모듈을 집중적으로 검증하고자 한다면 SAAM은 적합한 방법론이라 할 수 있다.
SAAM은 변화에 대한 아키텍쳐의 준비/고려 상태를 평가하기 때문에 정량화된 평가 결과를 도출하는데 어려움이 있을 수 있다. 다만 다양한 경험을 가진 전문가들의 의견을 하나의 시나리오를 기준으로 판단해봄으로써 향후 방향성을 설정하는데 의미 있는 결과를 얻을 수 있다.
SAAM을 통해서 프로젝트는 다양한 변경요구가 프로젝트에 미치는 영향을 다양한 stakeholder와 공유할 수 있게 하는 장점이 있다.
ATAM에 비해 Critical 한 Quality(ex 성능)를 다루지 않음으로써 보다 안전하게 적용할 수 있다.
Develop Scenarios
- 시스템이 지원해야 하는 모든 기능성에 대해서 도출한다.
- 시나리오 도출에 있어 다음을 고려한다.
- 시스템의 주요 사용
- 시스템의 사용자
- 미래의 변경 가능성
- 시스템이 지원해야 하는 Qualities
- 시나리오는 Brain storming을 통해서 추출된다. 다양한 관점의 관련 당사자들에 의해 시나리오는 도출될 것이며 경우에 따라서는 동일한 시나리오가 여러 사람에 의해 제기될 수도 있다. 또는 동일한 문제에 관련 있는 다른 관점의 시나리오들이 작성될 수도 있다.
- 시나리오는 몇 번의 Iteration을 통해서 도출될 수 있다.
Describe the Architecture(s)
후보 아키텍쳐나 아키텍쳐는 반드시 분석에 참여하는 사람들이 이해 가능한 표기법으로 기술되어야 한다.
아키텍쳐 Description은 시스템 컴퓨팅환경, data 컴포넌트, 그리고 그와 관련된 Connection을 포함해야 한다.
The development of scenarios and the description of architecture usually drive each other.
description of architecture는 시나리오에 관련한 아키텍쳐 결정을 관련 당사자들에게 알려주는데, 반면에 시나리오는 아키텍쳐에 대한 요구 사항을 반영하고 있다.
Classify and Prioritize the Scenarios
시나리오는 크게 direct scenario와 indirect scenario로 구분되어 진다.
Direct시나리오는 아키텍쳐 디자인 단계에서 이미 고려된 요구 사항들 이다. 따라서 SAAM을 통해서 관련 당사자들은 자신의 요구가 아키텍쳐에 어떻게 반영되었는지를 보다 잘 이해할 수 있다.
아키텍쳐를 수정 없이 반영되어 있는 시나리오를 direct 시나리오라 하고 현재의 아키텍쳐는 지원하지 않고 뭔가 수정이 일어나야만 지원되는 시나리오를 indirect 시나리오라고 한다.
Direct시나리오는 Use case와 유사하고 Indirect시나리오는 Change case와 유사하다.
시나리오는 중요한 순서로 정리되는데 이때 중요하다는 기준은 전적으로 관련 당사자들의 판단에 의존한다.
Individually Evaluate Indirect Scenarios
- 일단 시나리오가 선택되면 시나리오는 아키텍쳐 결정 사항에 멥핑된다.
- Direct scenario인 경우 아키텍트는 시나리오가 아키텍쳐에 의해 어떻게 실행되는지를 보인다.
- Indirect scenario인 경우 아키텍트는 시나리오를 위해 아키텍쳐를 어떻게 변경해야 하는지를 제시한다 ? SAAM
- Review에 참가하는 사람들은 아키텍쳐의 구조와 각 컴포넌트의 상호 작용에 대해 보다 깊이 이해하게 된다.
- 모든 indirect scenario를 위해 아키텍쳐 변경에 대한 비용이 추정되어야 한다.
- 아키텍쳐의 변경이라 함은 새로운 Component혹은 Connect 추가나 기존 Component/Connect의 변경을 의미한다.
- 본 타스크가 끝나면 모든 시나리오에 대해 direct/indirect구분이 되어야 하고 indirect 시나리오에 대한 아키텍쳐 변경의 비용이 리스트업 되어야 한다.
Assess Scenarios Interactions
- 둘 이상의 indirect시나리오를 위해 하나의 컴포넌트 변경을 수반할 때 그 컴포넌트에서 시나리오가 interact한다라고 말한다.
- 시나리오 interaction이 중요한 이유
- Product design에서 기능성 배치에 문제가 있음을 의미할 수 있고( poor separation of concerns)
- 시나리오 interaction은 아키텍쳐의 structural decomposition이 적절하게 이루어 지지 않았음을 암시한다.
- 만약 시나리오 interaction을 발견하고 해당 컴포넌트를 분할하여 interaction이 나타나지 않는다면 다시 Step2-Describe the Architecture(s)를 수행해야 한다.
Create the Overall Evaluation
마지막으로 시스템의 성공에 중요한 시나리오 순으로 가중치를 부여한다.
가중치는 주로 시나리오가 표현하는 비즈니스의 중요도와 상관관계를 갖는다.
가중치는 하나를 시스템을 위한 여러 아키텍쳐를 평가하는데 중요한 기준이 된다.
만약 여러 개의 아키텍쳐를 비교한다면 direct 시나리오 수를 평가하는 것도 가능하다 direct시나리오는 아키텍쳐를 수정하지 않고 수행 가능한 것들이기 때문에 아키텍쳐의 완성도를 판단하는데 도움을 줄 수 있다.
경우에 따라서 tabular summary를 만드는 것도 도움이 된다.
Sample Agenda for a SAAM
