목적
  • 스케줄 또는 예산에서 임의의 알려지지 않거나 감지된 위험을 밝혀내기 위함입니다.
  • 임의의 구조적 설계 결함을 발견하기 위함입니다. 구조적 결함은 수정하기에 가장 어렵고 긴 안목으로 볼 때 가장 손상을 입히는 것으로 알려져 있습니다.
  • 요구사항과 구조 간 잠재적 불일치(과도한 설계, 비현실적인 요구사항 또는 누락된 요구사항)를 발견하기 위함입니다. 특히, 평가는 조작, 관리 및 유지보수 영역에서 흔히 무시되는 면을 검사할 수 있습니다. 시스템이 설치된 방법. 갱신 여부. 현재 데이터베이스의 전이 방법.
  • 다음과 같은 하나 이상의 특정 구조적 품질을 평가하기 위함입니다. 성능, 신뢰성, 수정 가능성, 보안, 안정성.
  • 재사용 기회를 식별하기 위함입니다.
역할:  기술 검토자 
빈도: 특히 구현화 단계 중에 반복당 적어도 한 번.
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

일반 권장사항 페이지 맨 위

목적 각 검토에 대한 일반 권장사항.

20,000 피트에서 보면 임의의 기타 평가 또는 검토에서 소프트웨어 구조 평가를 구별하는 것이 그리 많지 않습니다.

그러나 소프트웨어 구조의 한 가지 중요한 특성은 여러 구조적 품질 속성에 대한 특정 측정치 결여입니다. 오직 소수의 구조적 품질이 객관적으로 측정될 수 있습니다. 성능은 측정이 가능한 한 예입니다. 기타 품질은 보다 질적이며 주관적입니다(예: 개념적 무결성). 더우기, 비교할 기타 데이터나 참조가 없는 경우에 메트릭의 의미를 판별하는 것은 어렵습니다. 대상 관객이 참조 시스템을 사용하고 이해할 수 있는 경우, 이 참조 시스템과 비교한 일부 검토 결과를 표현하는 것이 종종 편리합니다. 설계 중인 시스템이 초기 설계와 비교될 수 있는 상황에서 발생할 수 있습니다.

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

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

  1. 초기 개발 주기의 초기 단계의 마지막에 일반적으로 적당한 구체적 구조가 거의 없습니다. 그러나 검토로 일부 비현실적인 목표, 누락된 부분, 기존 제품의 재사용을 위해 놓친 기회 등을 밝힐 수 있습니다.
  2. 소프트웨어 구조 평가의 가장 자연스러운 위치는 구현화 단계의 마지막입니다. 이 단계는 기본적으로 요구사항을 자세히 조사하고 구조의 기준선 설정에 중점을 둡니다. 구조 검토는 해당 이정표에서는 RUP에게 위임됩니다. 이는 광범위한 구조적 품질이 조사되는 경우입니다.
  3. 특정 품질 속성(예: 성능 또는 안전)을 검사하도록 구성 단계 중과 제품을 일반 사용자에게 출시하는데 적합하지 않게 할 수도 있는 임의의 미련이 가는 문제점을 검사하도록 구성 단계 말기에 보다 중점된 평가가 수행될 수도 있습니다.
  4. 다음과 같이 사항이 정말로 잘못된 경우, 손상 제어 평가는 구성의 마지막 또는 전이 단계에서도 발생할 수 있습니다. 구성이 완료되지 않거나 전이 중에 승인 불가능한 레벨의 문제점이 설치된 기본에서 제기된 경우.
  5. 마지막으로, 평가는 전이의 마지막에서 특히 최종적인 새 제품 또는 전개 주기의 재사용 가능한 자산을 재고 목록으로 정리하기 위해 발생할 수 있습니다.

"피어" 검토자에는 비록 보다 제한되게 기술적 문제점에 중점을 둔 프로파일이지만 역할: 소프트웨어 아키텍트의 프로파일과 동일한 인력 프로파일이 있습니다. 리더쉽, 완성도, 실용주의 및 결과 지향은 덜 중요하지만 다음과 같은 경우에 여전히 중요합니다. 검토자가 그다지 흔치 않은 구조 결함이 프로젝트 스케줄에 문제를 일으키는지 알아낼 수 있습니다. 또한 중요한 문제점은 초기에 제기하는 것이 좋습니다. 이 때, 프로젝트 팀을 잘못된 경로로 이끄는 스케줄을 무작정 따르는 대신 문제점을 해결할 수 있습니다. 구조 검토자는 비용에 대해 위험의 밸런스를 맞추어야 하며, 이는 프로젝트 성공의 보다 광범위한 문제점에 여전히 민감한 사안으로 남습니다. 구조 검토자는 또한 민감한 문제점을 제기하고 의논할 수 있는 설득력있는 의사소통자여야 합니다.

권장되는 검토 회의 페이지 맨 위

목적 검토 범위 및 목표를 정의합니다.
각 특정 범위/목표 조합에 사용되는 방법을 정의합니다. 

다음과 같이 다양한 접근법을 사용하여 검토를 수행할 수 있습니다.

  • 표시 주도
  • 정보 주도
  • 시나리오 주도
표시 주도 검토

구조의 표시를 획득(또는 빌드)한 다음 질문을 하고 이 표시를 기반으로 추론하십시오.

여기에는 구조에 대한 대단한 지식이 있어 일부 알기 쉬운 설명을 제공하여 이로써 시작할 수 있게 하는 조직에서 소프트웨어 아키텍트(일부 다른 이름으로 숨겨지기가지 함)를 식별하여 해당 아키텍트로부터 정보를 추출하는 조직 및 소프트웨어 구조가 완전히 알려지지 않은 개념인 조직까지 광범위한 상황이 있습니다. 그런 다음, 이 프로세스는 "구조 마이닝"이라고 호명되며 실제로 문자 그대로 다음과 같습니다. 곡괭이로 소프트웨어 및 문서에서 파 내어 소스 코드, 인터페이스, 구성 데이터 등을 보기.

표시를 구성하는데 사용할 수 있는 한 모델은 소프트웨어 구조 문서에 표시된 구조 보기의 형식입니다. 논리적 보기가 기본 클래스(객체 모델)를 체계화하며 프로세스 보기가 제어의 기본 스레드와 해당 스레드 간 의사소통 방법을 설명합니다. 개발 보기가 다양한 서브시스템 및 해당 종속성을 표시하며 실제 보기가 기타 보기의 요소를 하나 또는 여러 실제 구성에 맵핑을 설명합니다. 여러 보기와 함께 문제점을 구성하십시오.

정보 주도 보기

정보 데이터와 추론에 필요한 측정값의 목록을 설정하고 정보를 얻은 다음 이 정보를 요구사항 또는 일부 승인된 참조 표준과 비교하십시오. 이는 특정 품질 속성(예: 성능 또는 견고성)을 조사하는데 제대로 적용됩니다.

시나리오 주도 검토

이는 조직적인 "가정" 접근법입니다. 질문되는 일반 질문사항을 시스템이 이행해야 하는 시나리오 세트로 변형하고 시나리오를 기반으로 질문을 하십시오. 이러한 시나리오의 예는 다음과 같습니다.

  • 시스템이 플랫폼 X와 Y에서 실행합니다(조사된 실제 품질 속성은 이식성임).
  • 시스템이 이 (추가) 기능 F를 수행합니다(실제 품질 속성은 확장 가능성임).
  • 시스템이 시간당 200개의 요청을 처리합니다(실제 품질 속성은 범위성임).
  • 시스템이 일반 사용자에 의해 이 유형이 사이트에 설치 중입니다(실제 품질 속성은 완전성 또는 사용성임).

이러한 접근법의 이점은 타스크를 매우 구체적인 Perspective로 모든 조직이 이해 가능한 상태로 둔다는 것입니다. 또한 특히 요구사항이 비공식적이거나 글로 작성되지 않았거나 매우 일반적이며 간결한 경우에 요구사항의 누락사항 또는 결함을 자세히 조사하게 합니다. 불리한 점은 구조 자체를 검토 중인 객체로서 여기지 않고 시스템을 일부 조사 사항을 전송 중인 블랙 박스로 간주합니다.

실제로, 이러한 사항은 그다지 명확히 분리되지 않으며 세 가지 접근법 모두의 일부를 수행하게 됩니다.

식별 문제점

잠재적 문제점을 밝히는 것은 대부분 지식과 경험을 기반으로 한 휴먼 판단에 의해 수행됩니다. 특정 실패 패턴이 프로젝트 간 및 조직 간에 반복됩니다. 특정 발견적 방법을 사용하여 문제점 영역을 밝힐 수도 있습니다. 이전 검토에서의 결과뿐 아니라(있는 경우) 체크리스트가 유용할 수 있습니다(일부 매우 일반적인 사항은 나중에 제안됨).

잠재적 문제점이 표시되는 대로 캡처하여 중립적인 어조로 설명하십시오(정확하게 지시 또는 "비극주의' 아님). AT&T 검토자와 같이 작은 마분지 카드를 사용하거나 우리와 같이 CRC 카드를 사용하여 우선순위 지정,체계화, 제거에 도움을 줄 수 있습니다.

나중에, 감소하는 범위 또는 영향별로 후보 문제점을 정렬하고 여러 개가 있는 경우, 가장 가까운 질문과 직접 관련된 문제점을 우선 다루고 시간이 허용하는 경우 "기타 제안사항"은 다음으로 남겨 두십시오. 그런 다음, 문제점의 실체를 주장하십시오. 매우 종종 문제점을 이해하지만 그 실체가 역설되지는 않습니다. 적당한 사람과 이야기를 하지 못했거나 정보의 적당한 부분을 살펴보지 않았을 뿐입니다. 다시 정렬하십시오. 문제점의 실체를 확인하도록 여러 데이터 지점을 확인하십시오(경험이 없는 주장자는 너무나 단일 스레드적인 경향이 있음).

문제점이 확인되면 시스템의 재설계를 연속적으로 수행할 필요없이 문제점을 제거할 수 있는 사항을 빠르게 검사하십시오. 잠재적 단순화 사항, 재사용 및 대안을 기록하십시오(예를 들어, 구매 대 빌드).

결함 해결책 책임 할당 페이지 맨 위

목적 식별된 결함에서 조치를 수행하기 위함입니다.  

검토 후에 각 식별된 보기에 책임을 할당하십시오. 이 경우, "책임"은 결함을 수정하는 것이 아닐 수 있지만 대안의 추가 조사를 조정하거나 결함의 해결책이 원대하거나 광범위한 경우 이를 조정합니다.



Rational Unified Process   2003.06.15