아키텍쳐가 처음에 의도했던 방향대로 제대로 설계되었는지를 검증하는 분석 방법론으로, 설계된 아키텍쳐가 시스템 성능, 가용성, 확정성 등과 같은 비기능 요구사항에 대한 항목에 대해 초기에 의도했던 품질 목표를 만족시키고 있는지 분석하고, 여러 가지 품질 목표가 상호간에 어떻게 작용하는지 파악하는 것이 주요 역할이다.

ATAM은 일반적인 아키텍쳐 분석 방법과 유사하지만, 특히 다음과 같은 점이 중요하다.

  • “이해 당사자의 능동적이고 적극적인 참여”,
  • “핵심 이해 당사자의 충분한 준비”,
  • “아키텍쳐 디자인 이슈와 분석 모델에 대한 이해”,
  • “비기능 요구사항에 대한 명확한 정리”

ATAM을 통해 비기능 요구사항에 대한 자세한 분석, 아키텍쳐의 결정사항에 대한 이해, 그리고 그 결정사항이 요구사항을 만족시킬 수 있는지를 분석할 수 있다.

아키텍쳐 평가의 목적은 설계된 아키텍쳐의 결함을 확인하고, 비기능 요구사항의 관점에서 평가하는 것이 목적이며 아키텍쳐의 잠재적인 위험 요소를 감지하는 도구 역할을 한다. 이 평가 절차는 소프트웨어 개발 주기의 초기 단계에서 수행할 수 있으며, 구현이 아닌 설계된 디자인을 평가하기 때문에 상대적으로 비용이 저렴하고 빠르다는 것이 장점이다.

또한 아키텍쳐의 중요성을 일깨우고 아키텍쳐와 관련된 산출물의 수준을 높이는 것과 함께 아키텍쳐 분석 시 위험요소, Trade-off 요소등에 대해 파악하고 향후 개선안을 도출하는 것이 이 평가의 중요한 목표이다.

ATAM Process


Present the ATAM

평가팀이 모든 이해 관계자에게 평가 절차에 대해서 설명하는 단계이다. 평가 자체에 대한 설명 및 평가를 진행하는 동안 지켜야 할 여러 가지 규칙에 대해서 설명한다. 참여자에게 평가를 통해 얻을 수 있는 기대사항 등을 질의하며, 평가팀 멤버의 역할 및 다른 참여자의 역할에 대해 설명한다. 평가가 진행되는 동안 생성되는 유틸리티 트리, 시나리오, 아키텍쳐 접근 방법, 아키텍쳐 분석을 위한 기술 및 위험요소, Trade-off 목록에 대해서 자세히 설명하여 적극적인 참여를 유도한다.

Present the Business Drivers

프로젝트의 PM이 비즈니스 관점에서 평가팀에게 시스템에 대해서 설명하는 단계이며 다음의 사항을 위주로 설명한다.
  • 가장 중요한 기능적 요구사항?????
  • 기술적, 관리적, 정치적 제약사항
  • 비즈니스 목표
  • 중요한 이해관계자
  • 품질 목표를 만족시키기 위한 아키텍쳐의 중요사항 평가팀은 비즈니스 드라이버 소개를 듣고 난 후 평가될 시스템의 범위를 정하고, 언급된 이해 관계자, 중요 품질 목표, 제약사항 등을 이해하고 목록을 작성한다.

    Present the Architecture

    아키텍트가 평가팀에게 아키텍쳐에 관해서 가능한 자세하게 설명하는 단계이다.

  • OS, 하드웨어, 미들웨어 등 이미 결정된 기술적인 제약사항
  • 연동해서 사용해야 하는 다른 시스템
  • 품질 요소를 만족시키기 위해 사용한 아키텍쳐 접근 방법

    절차 기록자는 아키텍트가 설명할 때 중요 부분을 기록한다.

    평가팀은 소개된 아키텍쳐 접근 방법, 잠재 위험요소, 추가적인 이해 관계자의 역할 등을 이해한다.

    Identity the Architectural Approaches

    [Present the Architecture]에서 소개된 아키텍쳐 고유의 접근 방법과 아키텍쳐 스타일을 파악하는 단계이다.

    아키텍쳐 접근방법을 확인하는 방법으로는 S/W 아키텍트에게 질의할 수도 있으며 각각의 평가팀 멤버에게서 투표로써 접근방법을 조사할 수도 있다.

    시나리오 기록자는 파악된 아키텍쳐 접근 방법을 기록한다 .

    Generate the Quality Attribute Utility Tree

    평가팀, 아키텍쳐 팀, 프로젝트 매니저 등이 협력하여 유틸리티 트리를 작성하는 단계이다.

    이 단계에서 만들어진 유틸리티 트리는 이후의 평가 스텝에서 가이드 역할을 하며 분석의 목표를 구체화하는 효과를 기대할 수 있다.

    유틸리티 트리를 통해 평가팀이 아키텍쳐의 어느 부분에 집중해야 할 지 등을 파악하고 평가의 범위를 결정하는 데 도움이 된다.


    유틸리티 트리를 생성하는 절차
    1. 루트에 “유틸리티”를 할당한다.
    2. 루트의 하위 노드인 레벨2에 시스템의 품질요소를 할당.(예: Performance, Maintainability 등)
    3. 레벨2 노드를 정제하여 레벨3 노드를 생성한다.
    4. 레벨4 노드로서 품질 시나리오를 생성한다.
    5. H/M/L 단위를 사용하여 시나리오의 중요도를 선정한다.
    6. H에 할당된 시나리오에 대해 그 시나리오를 수행하기가 얼마나 어려운지 아키텍트에게 질의한다.
    7. 품질요구 사항과 트리에서 나타난 중요 품질 요소 차이를 확인한다.
    8. 유틸리티 트리를 기록한다 .

    Analyze the Architectural Approaches

    유틸리티 트리를 통해 평가 범위를 결정한 후, 아키텍쳐 접근 방법과 결정사항을 평가하는 단계로 아키텍쳐의 중요한 부분을 알아낸다.

    이 단계의 가장 중요한 결과물은 Risk, Sensitivity point, Trade-off 등이며, 이들을 유틸리티 트리의 시나리오와 연계하여 품질요소에 대해 평가한다.



    Brainstorm and Prioritize Scenarios

    전체 이해 관계자로부터 시나리오를 생성하는 단계이다. 이 시나리오는 전체 이해관계자가 참여하는 투표 프로세스를 통해 우선순위가 정해진다.

    유틸리티 트리는 시나리오를 생성하기 위한 하향식 메커니즘을 제공하는 반면에, 시나리오 Brainstorming은 상향식 접근법으로 시나리오를 생성하는 것이다.

    평가 리더는 이해 관계자가 차례로 시나리오에 대해 말할 수 있도록 라운드로빈 방식으로 진행시킨다.

    시나리오 기록자는 Brainstorming 결과를 기록하여 전 참여자가 볼 수 있도록 게시한다.

    참여자는 게시된 시나리오 결과에 대해 토론하여 합치거나 삭제하여 시나리오를 정제한다.

    시나리오가 결정된 후 투표를 실시한다.

    결정된 시나리오의 수의 30%의 투표권을 할당한다. 
    예를 들면 시나리오의 개수가 20 개라면 각각의 참여자가 투표수는 여섯 표씩 투표할 수 있다. 투표 결과로 높은 우선순위의 시나리오는 다음 스텝에서 분석 대상이 된다


    상위에 랭크된 시나리오 사례


  • 시나리오 별 관련 품질속성

    Analyze the Architectural Approaches

    태스크2에서 선정된 높은 우선순위의 시나리오를 분석한다. 부가적인 아키텍쳐 접근 방법, 위험 요소, 민감 요소 등을 찾아낸다 .

    Present the Results

    스텝 1~2 를 통해 수행한 평가 결과에 대해 최종 보고서를 작성한다

    Two Faces of the ATAM



    '아키텍처와 공학' 카테고리의 다른 글

    프로젝트위험신호  (0) 2009.10.26
    CBD는 어디로 갔는가?  (0) 2009.10.26
    Software Architecture Analysis Method(SAAM)  (0) 2009.10.26
    파일럿(Pilot)과 프로토타이핑  (0) 2009.10.26
    재사용 효과  (1) 2009.10.26
    Posted by sjokim
    ,