목적
|
검토 범위 및 목적 정의
각 특정 범위/목적 조합에 사용되는 접근 방식 정의.
|
다른 종류의 접근 방식을 검토에 사용할 수 있습니다.
표시 기반 검토
아키텍처 표시를 확보(또는 빌드)하고 이 표시를 기반으로 질문을 하고 이유를 묻습니다.
아키텍처를 잘 알고 있어서 시작 가능한 알기 쉬운 설명을 제공하는 조직에서 부터 소프트웨어 설계자(이름이 다를 수도 있음)가 누구인지 식별하여 그로부터 정보를 추출해야 하는 조직과 소프트웨어 아키텍처의 개념이
전혀없는 조직에 이르기까지 여기에는 광범위한 상황이 존재합니다. 이 프로세스를 "아키텍처 마이닝"이라고 하며 실제로는 곡괭이를 사용하여 소프트웨어 또는 문서에서 소스 코드, 인터페이스, 구성 데이터 등을 캐내는
것과 같이 생각하면 됩니다.
표시를 조직하는 데 사용할 수 있는 하나의 모델은 소프트웨어 아키텍처 문서에 표시된 아키텍처 보기 형식입니다. 논리 보기가 기본 클래스(오브젝트 모델)를 조직하고 프로세스 보기는 제어 기본 스레드와 통신 방법을
설명하고 개발 보기는 다양한 서브시스템 및 종속성을 표시하며 실제 보기는 기타 보기 요소의 하나 이상의 실제 구성으로의 맵핑을 설명합니다. 여러 보기와 함께 문제를 조직합니다.
정보 기반 검토
논증에 필요한 정보(데이터, 측정) 목록을 작성하고 정보를 가져와서, 이 정보를 요구사항 또는 몇몇 허용 참조 표준과 비교하십시오. 이는 성능 또는 튼튼함과 같은 특정 품질 속성 검사에 적용됩니다.
시나리오 기반 검토
이는 조직적인 "가상(what if)" 접근 방식입니다. 주어진 일반 질문을 시스템에서 수행해야 하는 시나리오 세트로 변환하여 해당 시나리오를 기반으로 질문하십시오. 다음은 시나리오 예제입니다.
-
시스템은 플랫폼 X와 Y에서 실행됩니다. (적용된 실제 품질 속성은 이식성입니다.)
-
시스템은 (추가) 기능 F를 수행합니다. (실제 품질 속성은 확장성입니다.)
-
시스템은 시간당 200개의 요청을 처리합니다. (실제 품질 속성은 크기 조정 가능성입니다.)
-
사용자가 이런 종류의 사이트에 시스템을 설치합니다. (실제 품질 속성은 완전성 또는 사용성입니다.)
이 접근 방식을 사용하면 타스크가 매우 명확하게 되어 모든 관련자가 쉽게 이해할 수 있는 장점이 있습니다. 또한 요구사항의 누락 또는 결점을 자세히 조사할 수 있고 특히 요구사항이 비정규 상태이거나 또는 작성되지
않은 상태 또는 매우 일반적이고 짧은 경우에 유용합니다. 또한 검토 중인 오브젝트로 아키텍처 자체를 책정하지 않고, 시스템을 일부 조사 결과를 송신하기만 하는 블랙 박스로 사용하는 단점이 있습니다.
실제로는 상황이 그다지 명확하게 구분되지는 않으며, 세 가지 모든 접근 방식을 약간씩 설명했습니다.
문제 식별
일반적으로 잠재적 문제 제시는 지식과 경험을 바탕으로한 사람의 판단으로 수행됩니다. 특정 실패 패턴은 프로젝트간이나 조직간에 반복됩니다. 특정 발견론적 방법이 문제점 영역 제시에 사용됩니다. 체크리스트가 매우
유용하며(매우 일반적인 체크리스트는 이후에 제시됨) 이전 검토 결과가 있는 경우 역시 매우 유용합니다.
잠재적 문제가 표시되면 캡처하고 매우 중용적인 자세로 설명하여 비판이나 "격변설"을 내놓지 않아야 합니다. AT&T 검토자가 하는 것처럼 작은 보드지 카드를 사용하거나 CRC 카드를 사용하여
우선순위 결정, 구성 또는 제거를 수행합니다.
이후에 범위 또는 영향을 줄여서 후보 문제를 정렬하고 많은 문제가 있는 경우 현재 질문에 연관된 문제부터 처리하고 시간이 허용되면 "기타 제안"은 이후로 미룹니다. 그런 후에 문제점의 현실성을 주장합니다. 종종
문제점을 인식하지만 실제로는 문제가 아닌 경우가 있습니다. 담당자와 얘기하지 않았거나 잘못된 정보를 살펴본 경우입니다. 다시 분류하십시오. 여러 데이터 위치를 확인하여 문제점의 현실성을 확인하십시오. (서투른
평가자는 너무 편향되는 경향이 있습니다.)
문제점이 확인되면 필요한 시스템 재디자인 작업을 즉시 실행하지 않고 문제점을 제거하는 방법을 빠르게 점검하십시오. 잠재적 단순화, 재사용 및 대체를 기록하십시오(예: 구매 대 빌드).
|