타스크: 아키텍처 검토
이 타스크는 아키텍처 검토 수행 시기 및 방법과, 검토의 찾은 결과를 처리하는 방법을 정의합니다.
원칙: 분석 및 디자인
목적
  • 스케줄 또는 예산에 있어서의 알 수 없는 또는 인식된 위험성을 표시.
  • 모든 아키텍처 디자인 결점을 발견. 아키텍처 결점은 수정하기 가장 어려운 문제로 알려져 있고 장기적으로는 가장 치명적인 결과를 초래합니다.
  • 초과 디자인, 비현실적인 요구사항 또는 누락된 요구사항과 같이 요구사항과 아키텍처의 잠재적인 불일치 발견. 특히 평가는 오퍼레이션, 관리 및 유지보수에서 간과되는 몇몇 분야를 점검합니다. 시스템이 어떻게 설치되었습니까? 갱신했습니까? 현재 데이터베이스의 전이 방법은 무엇입니까?
  • 성능, 신뢰성, 수정 가능성, 보안, 안전성과 같은 하나 이상의 특정 아키텍처 품질 평가.
  • 재사용 기회 식별
관계
단계
일반 권장사항
목적 각 검토의 일반 권장사항.

넓게 보면 소프트웨어 아키텍처 평가는 기타 평가 또는 검토와 그다지 다르지 않습니다.

그러나 소프트웨어 아키텍처의 중요한 한 가지 특성은 많은 아키텍처 품질 속성에 대한 특정 측정이 없고 몇몇 아키텍처 품질만 객관적으로 측정될 수 있습니다. 측정이 가능한 품질 속성의 예제로는 성능이 있습니다. 기타 품질은 정성적이거나 주관적입니다(예: 개념적인 무결성). 더구나 비교할 기타 데이터 또는 참조가 없는 경우 메트릭이 나타내는 의미를 결정하기는 매우 어렵습니다. 참조 시스템이 사용 가능하고 대상 독자가 이를 이해하는 경우, 일부 검토 결과를 이 참조 시스템에 상대적인 값으로 표시하는 것이 편리할 경우도 있습니다. 이러한 상황은 디자인 중인 시스템을 초기 디자인과 비교할 수 있는 경우에 발생할 수 있습니다.

이 평가가 발생하는 라이프사이클에서 목적 또는 유용성에 영향을 줍니다.

프로젝트 라이프사이클 반복 다이어그램

  1. 초기 개발 주기의 도입/인식(Inception) 단계 종료부에는 일반적으로 아직 완벽하지 않은 아키텍처가 수립됩니다. 그러나 검토에서 비현실적인 목표, 누락된 내용, 기존 제품 재사용 기회 손실 등에 대한 내용을 표출하게 됩니다.
  2. 소프트웨어 아키텍처 평가의 가장 일반적인 위치는 정제(Elaboration) 단계의 종료부입니다. 이 단계는 주로 자세한 요구사항 탐색 및 아키텍처 기준선 지정에 초점을 맞춥니다. 아키텍처 검토는 이 이정표에서 RUP가 지시합니다. 이는 광범위한 아키텍처 품질을 점검하는 경우입니다.
  3. 구현/구축(Construction) 단계에서는 평가에 더 초점을 맞춰 성능 또는 안전과 같은 특정 품질 속성을 점검하고, 구현/구축 단계 종료 시점에서는 제품을 사용자에게 인도하기에 부적절하게 하는 남은 문제에 대해 초점을 맞춘 평가를 수행합니다.
  4. 구현/구축이 완료되지 않거나 전이 중에 설치된 기본 제품에 수용할 수 없는 레벨의 문제가 발생하는 등 실제로 문제가 발생하는 경우 손상 제어 평가는 구현/구축 후반 또는 전이 단계에서 수행됩니다.
  5. 전이 단계 종료부에서 마침내 평가가 수행됩니다(특히, 최종적인 새 제품 또는 발전 주기의 재사용가능한 자산 인벤토리에 대해).

"피어" 검토자는 역할: 소프트웨어 설계자와 동일한 인력 구성 프로파일을 갖게 되지만 기술적인 문제에 초점을 맞춥니다. 지도력, 성숙도, 실용주의 및 결과 지향은 많이 중요하다고는 볼 수 없지만 여전히 중요한 문제입니다. 검토자는 잘 알려지지 않은 아키텍처 결함이 프로젝트 스케줄에 영향을 준다면 이를 찾아낼 수도 있습니다. 그러나 프로젝트 팀이 맹목적으로 스케줄만 지켜서 결국 잘못된 경로를 밟을 수도 있기 때문에 문제를 해결할 수 있는 경우에는 조기에 중요한 문제를 부각시키는 것이 좋습니다. 아키텍처 검토자는 프로젝트 성공의 광범위한 문제들을 인식한 상태로 비용 대비 위험성의 밸런스를 유지해야 합니다. 아키텍처 검토자는 중요한 문제를 제기하고 논의할 수 있는 설득력이 있는 커뮤니케이션 능력이 있어야 합니다.

권장되는 검토 회의
목적 검토 범위 및 목적 정의
각 특정 범위/목적 조합에 사용되는 접근 방식 정의. 

다른 종류의 접근 방식을 검토에 사용할 수 있습니다.

  • 표시 기반
  • 정보 기반
  • 시나리오 기반
표시 기반 검토

아키텍처 표시를 확보(또는 빌드)하고 이 표시를 기반으로 질문을 하고 이유를 묻습니다.

아키텍처를 잘 알고 있어서 시작 가능한 알기 쉬운 설명을 제공하는 조직에서 부터 소프트웨어 설계자(이름이 다를 수도 있음)가 누구인지 식별하여 그로부터 정보를 추출해야 하는 조직과 소프트웨어 아키텍처의 개념이 전혀없는 조직에 이르기까지 여기에는 광범위한 상황이 존재합니다. 이 프로세스를 "아키텍처 마이닝"이라고 하며 실제로는 곡괭이를 사용하여 소프트웨어 또는 문서에서 소스 코드, 인터페이스, 구성 데이터 등을 캐내는 것과 같이 생각하면 됩니다.

표시를 조직하는 데 사용할 수 있는 하나의 모델은 소프트웨어 아키텍처 문서에 표시된 아키텍처 보기 형식입니다. 논리 보기가 기본 클래스(오브젝트 모델)를 조직하고 프로세스 보기는 제어 기본 스레드와 통신 방법을 설명하고 개발 보기는 다양한 서브시스템 및 종속성을 표시하며 실제 보기는 기타 보기 요소의 하나 이상의 실제 구성으로의 맵핑을 설명합니다. 여러 보기와 함께 문제를 조직합니다.

정보 기반 검토

논증에 필요한 정보(데이터, 측정) 목록을 작성하고 정보를 가져와서, 이 정보를 요구사항 또는 몇몇 허용 참조 표준과 비교하십시오. 이는 성능 또는 튼튼함과 같은 특정 품질 속성 검사에 적용됩니다.

시나리오 기반 검토

이는 조직적인 "가상(what if)" 접근 방식입니다. 주어진 일반 질문을 시스템에서 수행해야 하는 시나리오 세트로 변환하여 해당 시나리오를 기반으로 질문하십시오. 다음은 시나리오 예제입니다.

  • 시스템은 플랫폼 X와 Y에서 실행됩니다. (적용된 실제 품질 속성은 이식성입니다.)
  • 시스템은 (추가) 기능 F를 수행합니다. (실제 품질 속성은 확장성입니다.)
  • 시스템은 시간당 200개의 요청을 처리합니다. (실제 품질 속성은 크기 조정 가능성입니다.)
  • 사용자가 이런 종류의 사이트에 시스템을 설치합니다. (실제 품질 속성은 완전성 또는 사용성입니다.)

이 접근 방식을 사용하면 타스크가 매우 명확하게 되어 모든 관련자가 쉽게 이해할 수 있는 장점이 있습니다. 또한 요구사항의 누락 또는 결점을 자세히 조사할 수 있고 특히 요구사항이 비정규 상태이거나 또는 작성되지 않은 상태 또는 매우 일반적이고 짧은 경우에 유용합니다. 또한 검토 중인 오브젝트로 아키텍처 자체를 책정하지 않고, 시스템을 일부 조사 결과를 송신하기만 하는 블랙 박스로 사용하는 단점이 있습니다.

실제로는 상황이 그다지 명확하게 구분되지는 않으며, 세 가지 모든 접근 방식을 약간씩 설명했습니다.

문제 식별

일반적으로 잠재적 문제 제시는 지식과 경험을 바탕으로한 사람의 판단으로 수행됩니다. 특정 실패 패턴은 프로젝트간이나 조직간에 반복됩니다. 특정 발견론적 방법이 문제점 영역 제시에 사용됩니다. 체크리스트가 매우 유용하며(매우 일반적인 체크리스트는 이후에 제시됨) 이전 검토 결과가 있는 경우 역시 매우 유용합니다.

잠재적 문제가 표시되면 캡처하고 매우 중용적인 자세로 설명하여 비판이나 "격변설"을 내놓지 않아야 합니다. AT&T 검토자가 하는 것처럼 작은 보드지 카드를 사용하거나 CRC 카드를 사용하여 우선순위 결정, 구성 또는 제거를 수행합니다.

이후에 범위 또는 영향을 줄여서 후보 문제를 정렬하고 많은 문제가 있는 경우 현재 질문에 연관된 문제부터 처리하고 시간이 허용되면 "기타 제안"은 이후로 미룹니다. 그런 후에 문제점의 현실성을 주장합니다. 종종 문제점을 인식하지만 실제로는 문제가 아닌 경우가 있습니다. 담당자와 얘기하지 않았거나 잘못된 정보를 살펴본 경우입니다. 다시 분류하십시오. 여러 데이터 위치를 확인하여 문제점의 현실성을 확인하십시오. (서투른 평가자는 너무 편향되는 경향이 있습니다.)

문제점이 확인되면 필요한 시스템 재디자인 작업을 즉시 실행하지 않고 문제점을 제거하는 방법을 빠르게 점검하십시오. 잠재적 단순화, 재사용 및 대체를 기록하십시오(예: 구매 대 빌드).

결함 분석 책임 할당
목적 식별된 결함 조치 실행. 

검토가 완료되면 식별된 각 결함에 책임을 할당하십시오. 이 경우 "책임"은 결함을 해결하기 위함이 아니라 대체의 추가 조사를 조정하거나 결함 분석이 광범위한 경우 결함 분석을 조정하기 위한 것입니다.



자세한 정보