경량 아키텍처 평가를 수행하는 좋은 방법은 무엇입니까?


9

기술적 인 AATA (Architecture Tradeoff Analysis Method) 및보다 비즈니스 지향적 인 CBAM (Cost Benefit Analysis Method ) 과 같은 아키텍처 평가 방법에 익숙 합니다. 그러나 이러한 방법은 상당히 규모가 크므로 여러 브레인 스토밍 세션, 프레젠테이션, 트레이드 오프를 설명하는 다양한 시나리오 개발 등을 규정합니다. 특정 크기의 프로젝트에는 유용하지만 일반적으로 내부 프로젝트 나 데스크톱 응용 프로그램에는 너무 큽니다. 소수의 개발자 (또는 그 이하)가 개발 했음에도 불구하고 개발자는 비록 작지만 상당히 엄격한 품질 제약 (성능, 확장 성, 적응성)이 있습니다.

내가 과거에 사용한 전형적인 사례는 한 명의 개발자 (또는 팀에 건축가가있는 경우)가 애플리케이션의 일반 아키텍처를 제안한 다음 화이트 보드에서 다른 팀과 논의하는 것입니다. 그리기 쉽고 이해하기 쉬운 의사 UML 표기법. 이는 일반적으로 아키텍처에 대한 피드백 및 일부 반복으로 이어집니다. 그러나 그것은 약간의 비공식적 인 경향이있어 나중에 모든 종류의 가정이 이루어 지므로 나중에 잘못된 결정이 될 수 있습니다.

ATAM 같은 방법은 일반적으로 모든 사람들이 적어도 아키텍처가 정확히 무엇을 토론 리드를 동의 할 때까지 아키텍처에 대해 깊이 생각하는 모든 이해 관계자를 강제 입니다 .

누구나 경량의 선행 아키텍처 평가를 수행 한 경험이 있습니까? 그렇다면 모범 사례는 무엇입니까?

답변:


6

간단한 평가의 핵심은 적시에 올바른 것을 평가하는 것입니다. 이 작업을 효과적으로 수행하는 방법에는 두 가지가 있습니다. 와 시나리오 기반의 평가 는 우선 순위가 높은 품질의 특성에만 초점 평가를 구동하기 위해 품질 속성 시나리오 및 유스 케이스를 사용합니다. 으로 위험 기반 평가 는 위험을 식별하고, 식별 된 위험 아키텍처 디자인 활동을 구동 할 수 있습니다.

이 두 가지 (어떤 관련이있는) 접근법을 탐색 할 수있는 두 권의 책이 있습니다.

Anthony Lattanze의 소프트웨어 인텐시브 시스템 설계는 아키텍처 중심 설계 방법론을 소개하고 간단한 시나리오 기반 평가를 다룹니다. SEI의 Quality Attributes Workshop에서 Lattanze를 인식 할 수 있으며 비슷한 아이디어가 있습니다.

충분한 소프트웨어 아키텍처 : George Fairbanks의 리스크 중심 접근 방식은 소프트웨어 시스템 아키텍처를 설계하고 평가하는 리스크 중심 접근 방식을 소개합니다. 또한 몇 가지있다 자신의 웹 사이트에서 무료로 장을 사용할 수 는 미리보기를 원한다면. 이 책의 원칙은 즉시 적용 할 수 있지만 접근 방식에는 특정 방법이 제공되지 않으므로 다른 영역의 아이디어를 결합해야합니다. 위험 을 식별 / 우선 순위 화하기위한 SEI의 지속적인 위험 관리 접근법을 적극 권장합니다 .

이러한 접근 방식의 기본 개념은 끝까지 기다리지 않고 갈 때 평가함으로써 평가 및 설계 비용을 절감한다는 것입니다. 이것은 화이트 보드를 둘러 보는 것보다 약간 더 무겁지만, 완전히 불린 ATAM만큼 비용이 많이 드는 곳은 아닙니다. 편안하다면 체리를 선택하여 특정 요구를 충족시킬 수 있습니다.

평가를 추진하기 위해 어떤 접근 방식을 사용하든 일반적인 아이디어는 동일합니다 ...

시작하기 전에 :

  • 품질 특성 시나리오 또는 위험, 우선 순위 지정 (만약 이것이 비공식적 일 수 있음)
  • Go / No-Go 결정에 대한 명확한 정의
  • 아키텍처 설명의 가장 최근 컷 (평가중인 아티팩트)

평가 세션에 앉아

  • 건축가는 아키텍처의 개요를 제공합니다
  • 보기를 통해 시나리오 또는 위험이 어떻게 충족되는지 보여줍니다.
  • 문제는 나중에 수정 될 것으로 기록됩니다
  • 역할 및 일반 절차는 Fagan 검사 (건축가 또는 저자, 중재자, 레코더)에 사용 된 절차와 유사합니다.
  • 세션은 시스템 크기에 따라 1-2 시간 정도 걸릴 수 있습니다.

세션이 끝나면 :

  • 식별 된 문제를 검토하고 이동 / 거부 기준이 충족되는지 확인하십시오. 일반적으로 모든 작업을 완료하려면 약 3 리뷰가 필요합니다. 충족되지 않으면 정제 및 실험을 계속하십시오 (또는 아키텍처 위험 완화).
  • 이것은 "전부 또는 전무"평가가 아닙니다. 아키텍처의 다른 부분은 "통과"할 수 있지만 다른 부분은 여전히 ​​수정이 필요합니다.

시나리오 기반 접근법이 어떻게 보일지에 대한 느낌을주기 위해 대학원에서 일한 캡 스톤 프로젝트의 공개 문서가 있습니다 . 이 문서는 약간 거칠지 만 ACDM의 맥락에서 시나리오 기반 접근 방식의 예를 제공하는 데 도움이 될 수 있습니다. 우리는 5 명으로 구성된 팀으로 약 35 개의 KLOC Java / GWT와 같은 일반적인 웹 기반 애플리케이션을 구축했습니다.


고마워 마이클, 훌륭한 답변과 내가 바로 적용 할 수있는 것.
Deckard

2

나는 비공식적 인 화이트 보드 토론부터 시작합니다. 오늘 필요한 응용 프로그램의 일부만 작성하고 구현 중에 점차 아키텍처가 등장하게하는 것을 좋아합니다. 사전에 발명하려고하는 것이 아니라 "건축 찾기"와 비슷합니다. 이 방법은 많은 사전 평가가 필요하지 않으며 중요한 사항 (작동중인 소프트웨어 제공)에 계속 집중하는 데 도움이됩니다.

물론 비 기능적 요구 사항 (메모리 제약 조건, 응답 시간, 동시 사용자 수 등)이 필요한 경우 시스템을 구현할 때이를 고려해야합니다.


1
팀이 처리하는 도메인과 품질에 경험이 있고 적시에 올바른 위험을 관리 할 수있는 한, 아키텍처의 진화는 훌륭합니다.
Michael
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.