소프트웨어 아키텍처의 품질 평가하기

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 토론 영어원문  제안 및 의견 피드백

Jorge Diaz, Senior Certified IT Architect, IBM Japan

2008 년 7 월 01 일

이 글은 기존 소프트웨어 아키텍처의 품질을 이해하기 위한 접근을 제시합니다. 이 글의 의도는 소프트웨어 아키텍처 평가나 품질 연구 노력에 포괄적인 레퍼런스를 제공하기보다는 유용한 방법을 제공하는 것입니다. 궁금한 것은 소프트웨어 아키텍처의 품질이 보다 잘 이해되고 강화될 수 있는 방법은 무엇인가입니다. 여기에는 몇 가지 가능한 답이 있습니다. 이 글의 핵심은 아키텍처적 평가를 통해 품질을 향상시키는 것입니다.

개요

이 글을 통해 카네기 멜론 대학교(Carnegie Mellon University)의 Software Engineering Institute(SEI)에서 정의한 소프트웨어 아키텍처를 평가하는 네 가지 방법에 대해 배워보자.

SEI는 소프트웨어 아키텍처 품질에 대해 많은 연구를 발표했다. 이 글은 높은 수준에서 SEI의 평가 방법을 설명한다. 각 단계와 사례 연구에 대한 노력과 결과 등 자세한 내용은 참고자료를 보라.

활동이 적절하다면 Rational Unified Process(RUP)에 의해 지정된 SLC(Software Life Cycle) 모델에 맞는 것이다. 이 모델은 업계의 최신 개발 성과 전반에 걸쳐 가장 대중적이고 유명하기 때문에 선택됐다. 여기서 설명하는 방법으로 통합하는 데 있어, 더 자세한 정보는 참고자료를 보자.

위로

배경

평가 방법에 대해 자세히 설명하기 전에 주요 배경에 대해 설명하겠다.

품질

품질을 정의하는 것은 그리 쉬운 일이 아니다. 기본적으로 "품질은 좋은 것을 말한다"라든지 "품질은 좋은 솜씨를 말한다"라고 할 수 있다. 모든 이들이 거의 모든 도메인에서 품질이 성공적인 결과를 낼 수 있기에 중요하다는 데 동의한다. 예를 들어 팀 스포츠의 경우 팀의 결속력은 경기의 승패를 좌우하는 데 주요한 변수가 된다. 요리에 있어 질 높은 재료는 일반적인 식탁이냐 훌륭한 식탁이냐를 가늠하는 잣대가 되기도 한다. 이런 긍정적인 개념이 소프트웨어 품질에도 적용될 수 있다. 품질이 높을수록 프로젝트가 성공할 확률이 높아진다.

프로젝트는 품질(quality)을 강화하면서 기능(features)을 늘리고 스케쥴(schedule)을 단축하는 목표를 두고 있다. 현실적으로 이 세 가지를 모두 충족하긴 힘들기 때문에 이는 대체로 실현 불가능하다. 예를 들어 품질과 기능을 높이려면 작업을 완성하는 데 더 많은 시간이 필요하다. 더 많은 시간을 할당할 수 없다면 각 작업(테스팅 포함)에 더 적은 시간을 투자해야 하므로 품질에 영향을 줄 수밖에 없다.

방법(methods)은 이 세 분야의 의존성을 낮춘다. 예를 들어 더 효율적으로 기능을 추가할 방법이 있다면(특화된 CASE 도구처럼, 사용이 간단한 것을 추가하는) 스케쥴과 전체 품질은 크게 영향을 받지 않는다. 나중에 설명할 방법은 품질을 향상시키는 데 집중하면서 의존성에 관심을 기울일 수 있도록 한다.

품질 속성

품질을 강화하는 방법을 이해하는 것이 소프트웨어 성과에 최우선 순위가 돼야 한다. 품질의 향상 이전에 측정과 분석이 이뤄져야 한다. 품질 속성은 품질을 측정, 분석하기 위한 컨텍스트를 제공한다.

품질 속성(Quality attributes)은 성능, 보안, 휴대성, 기능 등과 같은 특정 컨텍스트의 품질을 자세히 나타내는 요소다. 이 속성들은 관련된 것끼리 주어진 상황에서 직접 엮이는 것으로 완벽한 양(quantity)은 아니다. 예를 들어 고객이 휴대성에 별 관심이 없지만(모든 시스템이 같은 운영체제에서 작동할 때 그럴 수 있다) 성능을 중시한다면 성능 속성이 휴대성 속성보다 우선될 것이다. 이를 통해 고객과 관련이 있는 것이 무엇인지에 따라 작업 순서가 정해진다.

속성을 제대로 측정할 수 있으려면 작업을 더 세세히 나눠야 한다. 예를 들어 성능 속성은 데이터 대기 시간과 트랜잭션 전반으로 쪼개져야 한다. 이 시점에서 사용 가능한 매트릭스가 더 명확해진다. 이들 각각의 정제된 엔티티는 특정 시나리오로 더 쪼개지며 이는 요구사항 정보를 알아내는 좋은 방법이다.

소프트웨어 아키텍처의 적절성을 이해하는 데 요구사항과 품질 속성 간의 관계가 도움이 된다. 이런 매핑 없이는 특정 기능을 아키텍처 디자인에 넣는 이유를 제대로 이해하기 힘들다. 디자이너에게 이것이 상식이기 때문인가? 무역 관련 잡지가 제안한 것인가? 아니면 주주들에 의해 지정된 것인가? 요구사항과 품질 속성의 관계는 또한 클라이언트에게 중요한 것이 무엇인지 명확히 해 주기 때문에 효과적으로 작업에 우선순위를 매길 수 있다.

품질 속성으로 더 세밀하게 디자인할 수 있는 도구를 알아내는 데 도움이 되는 특정 시나리오를 만들 수 있다.

소프트웨어 아키텍처 분석

소프트웨어 아키텍처로 복잡한 소프트웨어 시스템을 만들 수 있다. 소프트웨어 아키텍처는 모든 것에 세밀하게 관심을 가지는 게 아니라 솔루션에 큰 영향을 주는 것들에 관심을 갖는다. 건축가가 건물을 지을 때 콘크리트를 제조하는 등의 자세한 기술에 관심을 가지기보다 집 짓기의 성공 여부에 관심을 갖는 것과 같다. 최근 소프트웨어 프로젝트에서는 솔루션 요소간의 주어진 상호 연결에 있어 한 사람이 모든 것을 관리하는 것이 매우 어려워지고 있다. 소프트웨어 아키텍트의 가장 중요한 업무 중 하나는 성공의 열쇠를 쥔 요소를 식별해 복잡함을 관리 가능한 부분으로 쪼개는 것이다. 다음의 논리적 단계는 품질, 품질 속성, 소프트웨어 아키텍처 중 역동성을 연구해 품질을 강화할 수 있는 방법을 이해하는 것이다. 이를 효과적으로 수행하기 위해 관련된 분석 접근을 설명하겠다.

위로

평가 방법

성공적인 아키텍처는 다양한 가이드라인과 베스트 프랙티스를 수반한다. SEI는 아키텍처의 향상과 평가를 위한 몇 가지 방법을 만드는 등 이 분야에서 광범위한 연구를 해 왔다. 가장 대표적인 네 가지 방법은 다음과 같다.

• Quality Attributes Workshop (QAW)
• Architecture Tradeoff Analysis Method (ATAM)
• Software Architecture Analysis Method (SAAM)
• Active Reviews for Intermediate Designs (ARID)

QAW는 아키텍처가 정의되기 전에 실행되고 ARID는 디자인 성과 중에 실행되는 반면 ATAM과 SAAM은 아키텍처가 완료된 후 실행된다. 이 방법들을 끌어내는 부분은 조언자(facilitator)의 몫이다. 이 방법들에 대한 더 자세한 정보는 참고자료를 보자.

Quality Attributes Workshop 방법

QAW 방법은 소프트웨어 아키텍처가 만들어지기 전에 품질 속성을 발견하기 위한 접근이다. 성능이나 보안 같은 특정 품질은 잘 디자인된 소프트웨어 아키텍처에 의해 크게 좌우된다.

품질 속성은 사라지기도 하고 완전히 지정되지 않기도 한다. 그래서 솔루션이 구현되는 생명주기 후기에 재앙이 될 수 있다. 예를 들어 속성은 컴포넌트에서 인프라스트럭처 요소까지 솔루션의 많은 레벨에 영향을 끼치기 때문에 시스템 보안이 초기에 잘 정의되지 않으면 나중에 추가하기 힘들다.

QAW 끌어내기 활동은 조언자와 시스템 책임자를 아우르는 워크샵에서 실행된다. QAW는 표 1에서 볼 수 있듯이 여덟 가지 단계로 나눈다.

QAW 성과의 결과는 아키텍처 드라이버, 시나리오, 시나리오의 우선순위를 매긴 목록, 치밀한 시나리오다. 이 정보를 사용해 요구사항, 개발 프로토타입, 중요한 디자인 결정 등을 다듬을 수 있다.

Architecture Tradeoff Analysis 방법

QAW 방법은 아키텍처가 결정되기 전에 품질 요소의 문서와 우선순위를 산출했다. ATAM은 아키텍처가 이미 만들어졌다고 가정한다. ATAM에서 QAW 성과는 명확한 품질 속성 정의를 만드는 데 재사용할 수 있다. ATAM은 아키텍처가 특정 품질 목표를 얼마나 잘 만족시키는가를 설명하므로 "절충(trade-offs)"을 포함하지만 아키텍처의 품질에서 이 속성들을 교환하는 데 통찰력을 발휘한다.

ATAM은 아키텍처를 점검하고 현재 아키텍처와 비즈니스 드라이버의 적합성을 평가하는 방법을 제시한다. 또한 책임자들이 필요로 하는 것과 솔루션 디자인을 좀 더 동기화하는 데 도움이 된다.

Software Architecture Analysis 방법

QAW와 ATAM에 앞서 나온 SAAM은 소프트웨어 아키텍처를 분석하는 최초의 문서화된 접근 중 하나로 ATAM보다 간단한 접근을 제공한다. SAAM의 혁신자 중 하나는 "내 아키텍처는 쉽게 보수할 수 있다"처럼 행하기 힘든 작업을 요구한다고 많은 아키텍트이 말했다. SAAM의 몇 가지 단계는 ATAM의 몇 단계와 같고 다른 부분은 표 3에서 찾을 수 있다.

SAAM은 더 직접적으로 테스트되는 환경을 가능하게 해 측정 가능한 품질 속성 시나리오를 일반 속성에 붙이는 방법을 제공한다.

Active Reviews for Intermediate Design 방법

ATAM과 SAAM은 모두 완성된 아키텍처에 집중하지만 ARID 방법은 완성되지 않은 아키텍처에 집중한다. 장점은 아키텍처 디자인이 완성돼 제대로 된 방향으로 가고 있는지 이해할 때까지 기다리지 않아도 된다는 것이다. 표 4는 그 단계를 보여준다.

여기서 설명한 방법 중 ARID가 가장 최신 방법이다. 다른 방법의 특성을 많이 공유했으므로 이미 검증된 기술을 많이 재사용한다.

위로

사용 패턴

실제 생활에서 이 방법들은 프로세스 프레임워크의 컨텍스트 내에서 사용될 것이며 이것이 RUP가 그림에 들어오는 시점이다. RUP는 검증된 소프트웨어 생명주기와 문서화된 페이즈, 잘 정의된 영역과 실용적인 역할을 정의한다. RUP의 핵심 원칙은 아키텍처 중심의 프로세스라는 것이다. 아키텍처는 RUP를 사용하는 어떤 애플리케이션이든 성공에 꼭 필요한 요소다. 대부분의 아키텍처 개발은 최초의 생명주기 단계에서 시작되며 후반 단계에서 필요한 만큼 수정된다.

QAW는 RUP의 최초 단계에 가장 적합하며 이후 아이디어가 결정되는 대로 아키텍처도 결정된다. QAW는 또한 이후 단계에서 최초로 발견을 정제하는 데 사용될 수 있다. 요구사항 영역은 QAW가 RUP에 가져오는 품질 속성 분석에 더 집중함으로써 장점을 가질 수 있다.

ARID는 RUP의 상세 단계인 소프트웨어 아키텍처 통합 단계에서 실행돼야 한다. ARID는 다양한 검열 성과가 RUP의 분석과 디자인 영역의 부분으로 실행되는 데 도움이 된다.

ATAM/SAAM 성과는 생명주기 어디서든 아키텍처 검열이 필요한 때 나타날 수 있다. 그 중에서도 아키텍처 계획에서 리소스가 실행되기 시작하는 RUP의 구성 단계에 적합하다. ATAM의 가져온 아키텍처를 품질 목표와 비교하는 능력은 QAW 결과를 재사용할 때 이상적이다.

위로

요약

다음 표는 이 글에서 설명한 방법을 어떻게 사용하는지 요약한 것이다. RUP SLC 단계의 사용 순으로 나열된다. 역할과 영역 역시 기존 지식 영역 내에서 성과를 더 잘 위치하도록 나열된다.

평가 방법을 사용하는 것은 현 아키텍처 디자인을 더 잘 이해할 수 있고 소프트웨어 아키텍처에서 품질을 더 효율적으로 결정할 수 있도록 한다. 요구사항을 시나리오 주도의 품질 속성과 맞추는 것은 더 정확한 소프트웨어 아키텍처에 도움이 된다. 이 글에서 설명한 방법은 이 연결 유형들의 촉매 역할을 해 기존에 명확히 볼 수 없었던 주요 관계를 객관화할 수 있도록 한다. 평가 방법을 사용하면 아키텍처 디자인의 적합성을 확인하고 품질을 강화하는 데 도움이 된다.

참고자료

• Software Engineering Institute는 미국 연방 정부에서 지원하는 연구소로 아키텍처와 제품 라인, 프로세스 향상과 성능 측정, 보안, 시스템 상호운용성과 의존성에 대한 소프트웨어 엔지니어링을 연구한다.
  
  
• Quality Attributes(Technical Report CMR/SEI-95-Tr-021, 1995)는 여러 가지 소프트웨어 품질 속성에 관한 논리성을 위한 통합된 접근에서 작게나마 발전에 기여했다. 품질 속성은 소프트웨어 품질을 정의하고 속성의 일반 분류를 소개하고 속성 간의 연결을 논의하고 소프트웨어 아키텍처 평가에 속성 기반 방법론을 도입하는 미래 지향적 작업에 대해 논의한다.
  
  
• Quality Attribute Workshops, 3rd Edition(Technical Report CMU/SEI-2003-TR-016)은 QAW 방법을 설명한다.
  
  
• "Making Architecture Reviews Work in the Real World"(IEEE, 2002)는 형식적 아키텍처 검열의 기술적이지 않은 부분, 즉 사회적, 정신적, 관리적 측면을 파헤친다.
  
  
• "Predicting Software Quality by Architecture-Level Evaluation"(Fifth International Conference on Software Quality, 1995)은 소프트웨어 개발 생명주기에서 가능한 빨리 품질의 적절성과 달성을 위해 소프트웨어 디자인을 평가하는 것의 중요함에 대해 다룬다.
  
  
• Clements, Kazman, and Klein의 2002년 연구인 Evaluating Software Architectures: Methods and Case Studies 는 실제 시스템에서 ATAM, SAAM, ARID 방법의 실용적 응용과 가치를 보여주는 자세한 실제 사례를 제공한다.
  
  
• Integrating Software Architecture Centric Methods into the Rational Unified Process(Technical Report CMU/SEI-2004-TR-011)는 카네기 멜론 SEI의 아키텍처 중심 방법을 RUP 프레임워크에 맞춘다.
  
  
• P. Kruchten의 The Rational Unified Process – An Introduction(2nd Edition) 은 전체 프로젝트의 건강을 위한 Rational의 처방을 소개한다.
  
  
• 한국 developerWorks Architecture 영역에서 아키텍처와 관련된 기술을 높이는 데 필요한 참고자료를 얻자.
  
  
• 기술 서점에서 관련 기술에 관한 책을 찾아보자.
  
  

• IBM 제품 평가판을 다운받아 애플리케이션 개발 도구와 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 미들웨어 제품에 익숙해지자.

• 포럼에 참여하기.
  
  
• developerWorks 블로그와 developerWorks 커뮤니티
  
  

필자소개

		Jorge Diaz는 WebSphere 소프트웨어 서비스 내의 수석 공인 IT 아키텍트로, 기술 변환과 솔루션 아키텍처 컨설팅에 관심을 갖고 있다. Jorge는 다양한 업계에서 광범위한 경험을 쌓아왔고 대형 고객을 위한 서비스 지향 아키텍처 채택에 탁월한 업무 성과를 보였다. 학부 전공은 컴퓨터 공학, 석사 전공은 소프트웨어 엔지니어링이며 다양한 분야에 기술 인증을 받았다. 현재 The Open Group의 SOA Working Group 위원이며 IEEE 수석 회원이자 ACM과 SEI 회원이다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로